From andrei.i.eremeev at mail.ru Tue Aug 2 11:48:49 2016 From: andrei.i.eremeev at mail.ru (=?UTF-8?B?QW5kcmVpIEVyZW1lZXY=?=) Date: Tue, 02 Aug 2016 14:48:49 +0300 Subject: =?UTF-8?B?UmU6IGpzaGVsbCAodGVzdHM/KSBsZWFraW5nIGZpbGVzIGluIC90bXA=?= In-Reply-To: <579BB20D.9060306@oracle.com> References: <579BB20D.9060306@oracle.com> Message-ID: <1470138529.50728900@f28.i.mail.ru> Hi Jon, As far as I remember, JShell uses temp files to edit code snippets in external editors. And it looks like JShell does not remove the files after editing. -- Andrei Eremeev Friday, 29 July 2016, 10:44PM +03:00 from Jonathan Gibbons jonathan.gibbons at oracle.com : >My /tmp is accumulating jshell files: > >$ find /tmp/jshell* >/tmp/jshelltemp1044549827386632150 >/tmp/jshelltemp1044549827386632150/8011562224044845728.edit >/tmp/jshelltemp1047969916921684187 >/tmp/jshelltemp1047969916921684187/1740671090630915795.edit >/tmp/jshelltemp1072678409055720780 >/tmp/jshelltemp1072678409055720780/978408699063547197.edit >/tmp/jshelltemp1200545436603537750 >/tmp/jshelltemp1200545436603537750/3390705712185362355.edit >/tmp/jshelltemp1221162966070216464 >/tmp/jshelltemp1221162966070216464/3081222915116288162.edit >/tmp/jshelltemp1425582075044687363 >/tmp/jshelltemp1425582075044687363/4082709690184420251.edit >/tmp/jshelltemp1577033095144892398 >/tmp/jshelltemp1577033095144892398/9081427157952395244.edit >/tmp/jshelltemp1585036544870564328 >/tmp/jshelltemp1585036544870564328/3906837717961713151.edit >/tmp/jshelltemp165895593330514486 >/tmp/jshelltemp165895593330514486/6627843380470403643.edit >/tmp/jshelltemp1833109810049396364 >/tmp/jshelltemp1833109810049396364/517769421906389157.edit >/tmp/jshelltemp2041981097096951060 >/tmp/jshelltemp2041981097096951060/2349577263460706006.edit >/tmp/jshelltemp2193900651454655061 >/tmp/jshelltemp2193900651454655061/6384782619469415234.edit >/tmp/jshelltemp2234949382818285124 >/tmp/jshelltemp2234949382818285124/4834457107790499447.edit >/tmp/jshelltemp2296337736965199344 >/tmp/jshelltemp2296337736965199344/8826222356240547610.edit >/tmp/jshelltemp2345658105656559252 >/tmp/jshelltemp2345658105656559252/6729333722014852729.edit >/tmp/jshelltemp2468675356543856110 >/tmp/jshelltemp2468675356543856110/6621846833826280297.edit >/tmp/jshelltemp2504345118557203640 >/tmp/jshelltemp2504345118557203640/5097858842709809254.edit >/tmp/jshelltemp2595239917647196066 >/tmp/jshelltemp2595239917647196066/4410162140727614450.edit >/tmp/jshelltemp2668148898346441797 >/tmp/jshelltemp2668148898346441797/1660414210153626169.edit >/tmp/jshelltemp3514984560124468983 >/tmp/jshelltemp3514984560124468983/6131864124091385623.edit >/tmp/jshelltemp3562125506660912173 >/tmp/jshelltemp3562125506660912173/8887290599369872073.edit >/tmp/jshelltemp40589362697391818 >/tmp/jshelltemp40589362697391818/8822906394660574353.edit >/tmp/jshelltemp4387371979722467975 >/tmp/jshelltemp4387371979722467975/7249033605230168031.edit >/tmp/jshelltemp4715020457318511491 >/tmp/jshelltemp4715020457318511491/4636728652227855346.edit >/tmp/jshelltemp52332485773094168 >/tmp/jshelltemp52332485773094168/1277048994347896757.edit >/tmp/jshelltemp5278128846699884471 >/tmp/jshelltemp5278128846699884471/44922152761642381.edit >/tmp/jshelltemp5320120409750616204 >/tmp/jshelltemp5320120409750616204/24459148772882266.edit >/tmp/jshelltemp5534152442553977652 >/tmp/jshelltemp5534152442553977652/8186176305757939505.edit >/tmp/jshelltemp5623564536996825207 >/tmp/jshelltemp5623564536996825207/9045016579988583399.edit >/tmp/jshelltemp5700044225140491973 >/tmp/jshelltemp5700044225140491973/3188060456352696621.edit >/tmp/jshelltemp6324874596657398893 >/tmp/jshelltemp6324874596657398893/3179325677151331223.edit >/tmp/jshelltemp6808171130698006683 >/tmp/jshelltemp6808171130698006683/319127357748973046.edit >/tmp/jshelltemp7001485162152525304 >/tmp/jshelltemp7001485162152525304/9168706811139870527.edit >/tmp/jshelltemp7069920922180135958 >/tmp/jshelltemp7069920922180135958/8686060872597749049.edit >/tmp/jshelltemp7088266688866808879 >/tmp/jshelltemp7088266688866808879/6924602628004312642.edit >/tmp/jshelltemp7173145703014422717 >/tmp/jshelltemp7173145703014422717/4607109423377503842.edit >/tmp/jshelltemp7180999435914656215 >/tmp/jshelltemp7180999435914656215/5549682196654974987.edit >/tmp/jshelltemp7208905856201817354 >/tmp/jshelltemp7208905856201817354/6181265411604183143.edit >/tmp/jshelltemp7680863956932965286 >/tmp/jshelltemp7680863956932965286/4077316136930888410.edit >/tmp/jshelltemp7853784893157006161 >/tmp/jshelltemp7853784893157006161/5787573000355892776.edit >/tmp/jshelltemp7992097935706702471 >/tmp/jshelltemp7992097935706702471/1856486408875906360.edit >/tmp/jshelltemp8128412259418228343 >/tmp/jshelltemp8128412259418228343/5002913207029300566.edit >/tmp/jshelltemp8227545996613827901 >/tmp/jshelltemp8227545996613827901/3843405868953231414.edit >/tmp/jshelltemp850631284448899163 >/tmp/jshelltemp850631284448899163/481600313656353994.edit >/tmp/jshelltemp8744516682365157187 >/tmp/jshelltemp8744516682365157187/5826738179758017666.edit >/tmp/jshelltemp8852008122297380391 >/tmp/jshelltemp8852008122297380391/3226693345657046477.edit >/tmp/jshelltemp9074215226291200769 >/tmp/jshelltemp9074215226291200769/8315526298738535034.edit >/tmp/jshelltemp9193145933675852815 >/tmp/jshelltemp9193145933675852815/8998940437928279313.edit > From vicente.romero at oracle.com Tue Aug 2 13:43:24 2016 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Tue, 2 Aug 2016 09:43:24 -0400 Subject: jshell (tests?) leaking files in /tmp In-Reply-To: <1470138529.50728900@f28.i.mail.ru> References: <579BB20D.9060306@oracle.com> <1470138529.50728900@f28.i.mail.ru> Message-ID: <7b8db89f-6fc2-e1da-918c-2bcca05a2bb2@oracle.com> Hi, IMO, I don't think that it's a good practice to write files to the /tmp folder. Users with no write permission might have problems to run the tests. Thanks, Vicente On 08/02/2016 07:48 AM, Andrei Eremeev wrote: > Hi Jon, > As far as I remember, JShell uses temp files to edit code snippets in external editors. And it looks like JShell does not remove the files after editing. > -- > Andrei Eremeev Friday, 29 July 2016, 10:44PM +03:00 from Jonathan Gibbons jonathan.gibbons at oracle.com : > >> My /tmp is accumulating jshell files: >> >> $ find /tmp/jshell* >> /tmp/jshelltemp1044549827386632150 >> /tmp/jshelltemp1044549827386632150/8011562224044845728.edit >> /tmp/jshelltemp1047969916921684187 >> /tmp/jshelltemp1047969916921684187/1740671090630915795.edit >> /tmp/jshelltemp1072678409055720780 >> /tmp/jshelltemp1072678409055720780/978408699063547197.edit >> /tmp/jshelltemp1200545436603537750 >> /tmp/jshelltemp1200545436603537750/3390705712185362355.edit >> /tmp/jshelltemp1221162966070216464 >> /tmp/jshelltemp1221162966070216464/3081222915116288162.edit >> /tmp/jshelltemp1425582075044687363 >> /tmp/jshelltemp1425582075044687363/4082709690184420251.edit >> /tmp/jshelltemp1577033095144892398 >> /tmp/jshelltemp1577033095144892398/9081427157952395244.edit >> /tmp/jshelltemp1585036544870564328 >> /tmp/jshelltemp1585036544870564328/3906837717961713151.edit >> /tmp/jshelltemp165895593330514486 >> /tmp/jshelltemp165895593330514486/6627843380470403643.edit >> /tmp/jshelltemp1833109810049396364 >> /tmp/jshelltemp1833109810049396364/517769421906389157.edit >> /tmp/jshelltemp2041981097096951060 >> /tmp/jshelltemp2041981097096951060/2349577263460706006.edit >> /tmp/jshelltemp2193900651454655061 >> /tmp/jshelltemp2193900651454655061/6384782619469415234.edit >> /tmp/jshelltemp2234949382818285124 >> /tmp/jshelltemp2234949382818285124/4834457107790499447.edit >> /tmp/jshelltemp2296337736965199344 >> /tmp/jshelltemp2296337736965199344/8826222356240547610.edit >> /tmp/jshelltemp2345658105656559252 >> /tmp/jshelltemp2345658105656559252/6729333722014852729.edit >> /tmp/jshelltemp2468675356543856110 >> /tmp/jshelltemp2468675356543856110/6621846833826280297.edit >> /tmp/jshelltemp2504345118557203640 >> /tmp/jshelltemp2504345118557203640/5097858842709809254.edit >> /tmp/jshelltemp2595239917647196066 >> /tmp/jshelltemp2595239917647196066/4410162140727614450.edit >> /tmp/jshelltemp2668148898346441797 >> /tmp/jshelltemp2668148898346441797/1660414210153626169.edit >> /tmp/jshelltemp3514984560124468983 >> /tmp/jshelltemp3514984560124468983/6131864124091385623.edit >> /tmp/jshelltemp3562125506660912173 >> /tmp/jshelltemp3562125506660912173/8887290599369872073.edit >> /tmp/jshelltemp40589362697391818 >> /tmp/jshelltemp40589362697391818/8822906394660574353.edit >> /tmp/jshelltemp4387371979722467975 >> /tmp/jshelltemp4387371979722467975/7249033605230168031.edit >> /tmp/jshelltemp4715020457318511491 >> /tmp/jshelltemp4715020457318511491/4636728652227855346.edit >> /tmp/jshelltemp52332485773094168 >> /tmp/jshelltemp52332485773094168/1277048994347896757.edit >> /tmp/jshelltemp5278128846699884471 >> /tmp/jshelltemp5278128846699884471/44922152761642381.edit >> /tmp/jshelltemp5320120409750616204 >> /tmp/jshelltemp5320120409750616204/24459148772882266.edit >> /tmp/jshelltemp5534152442553977652 >> /tmp/jshelltemp5534152442553977652/8186176305757939505.edit >> /tmp/jshelltemp5623564536996825207 >> /tmp/jshelltemp5623564536996825207/9045016579988583399.edit >> /tmp/jshelltemp5700044225140491973 >> /tmp/jshelltemp5700044225140491973/3188060456352696621.edit >> /tmp/jshelltemp6324874596657398893 >> /tmp/jshelltemp6324874596657398893/3179325677151331223.edit >> /tmp/jshelltemp6808171130698006683 >> /tmp/jshelltemp6808171130698006683/319127357748973046.edit >> /tmp/jshelltemp7001485162152525304 >> /tmp/jshelltemp7001485162152525304/9168706811139870527.edit >> /tmp/jshelltemp7069920922180135958 >> /tmp/jshelltemp7069920922180135958/8686060872597749049.edit >> /tmp/jshelltemp7088266688866808879 >> /tmp/jshelltemp7088266688866808879/6924602628004312642.edit >> /tmp/jshelltemp7173145703014422717 >> /tmp/jshelltemp7173145703014422717/4607109423377503842.edit >> /tmp/jshelltemp7180999435914656215 >> /tmp/jshelltemp7180999435914656215/5549682196654974987.edit >> /tmp/jshelltemp7208905856201817354 >> /tmp/jshelltemp7208905856201817354/6181265411604183143.edit >> /tmp/jshelltemp7680863956932965286 >> /tmp/jshelltemp7680863956932965286/4077316136930888410.edit >> /tmp/jshelltemp7853784893157006161 >> /tmp/jshelltemp7853784893157006161/5787573000355892776.edit >> /tmp/jshelltemp7992097935706702471 >> /tmp/jshelltemp7992097935706702471/1856486408875906360.edit >> /tmp/jshelltemp8128412259418228343 >> /tmp/jshelltemp8128412259418228343/5002913207029300566.edit >> /tmp/jshelltemp8227545996613827901 >> /tmp/jshelltemp8227545996613827901/3843405868953231414.edit >> /tmp/jshelltemp850631284448899163 >> /tmp/jshelltemp850631284448899163/481600313656353994.edit >> /tmp/jshelltemp8744516682365157187 >> /tmp/jshelltemp8744516682365157187/5826738179758017666.edit >> /tmp/jshelltemp8852008122297380391 >> /tmp/jshelltemp8852008122297380391/3226693345657046477.edit >> /tmp/jshelltemp9074215226291200769 >> /tmp/jshelltemp9074215226291200769/8315526298738535034.edit >> /tmp/jshelltemp9193145933675852815 >> /tmp/jshelltemp9193145933675852815/8998940437928279313.edit >> From jonathan.gibbons at oracle.com Tue Aug 2 14:31:24 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 02 Aug 2016 07:31:24 -0700 Subject: jshell (tests?) leaking files in /tmp In-Reply-To: <7b8db89f-6fc2-e1da-918c-2bcca05a2bb2@oracle.com> References: <579BB20D.9060306@oracle.com> <1470138529.50728900@f28.i.mail.ru> <7b8db89f-6fc2-e1da-918c-2bcca05a2bb2@oracle.com> Message-ID: <57A0AEBC.7080204@oracle.com> I think you can assume people will have write permission to /tmp, but it is still bad practice to write files there and not clean them up afterwards. -- Jon On 08/02/2016 06:43 AM, Vicente-Arturo Romero-Zaldivar wrote: > Hi, > > IMO, I don't think that it's a good practice to write files to the > /tmp folder. Users with no write permission might have problems to run > the tests. > > Thanks, > Vicente > > On 08/02/2016 07:48 AM, Andrei Eremeev wrote: >> Hi Jon, >> As far as I remember, JShell uses temp files to edit code snippets in >> external editors. And it looks like JShell does not remove the files >> after editing. >> -- >> Andrei Eremeev Friday, 29 July 2016, 10:44PM +03:00 from Jonathan >> Gibbons jonathan.gibbons at oracle.com : >> >>> My /tmp is accumulating jshell files: >>> >>> $ find /tmp/jshell* >>> /tmp/jshelltemp1044549827386632150 >>> /tmp/jshelltemp1044549827386632150/8011562224044845728.edit >>> /tmp/jshelltemp1047969916921684187 >>> /tmp/jshelltemp1047969916921684187/1740671090630915795.edit >>> /tmp/jshelltemp1072678409055720780 >>> /tmp/jshelltemp1072678409055720780/978408699063547197.edit >>> /tmp/jshelltemp1200545436603537750 >>> /tmp/jshelltemp1200545436603537750/3390705712185362355.edit >>> /tmp/jshelltemp1221162966070216464 >>> /tmp/jshelltemp1221162966070216464/3081222915116288162.edit >>> /tmp/jshelltemp1425582075044687363 >>> /tmp/jshelltemp1425582075044687363/4082709690184420251.edit >>> /tmp/jshelltemp1577033095144892398 >>> /tmp/jshelltemp1577033095144892398/9081427157952395244.edit >>> /tmp/jshelltemp1585036544870564328 >>> /tmp/jshelltemp1585036544870564328/3906837717961713151.edit >>> /tmp/jshelltemp165895593330514486 >>> /tmp/jshelltemp165895593330514486/6627843380470403643.edit >>> /tmp/jshelltemp1833109810049396364 >>> /tmp/jshelltemp1833109810049396364/517769421906389157.edit >>> /tmp/jshelltemp2041981097096951060 >>> /tmp/jshelltemp2041981097096951060/2349577263460706006.edit >>> /tmp/jshelltemp2193900651454655061 >>> /tmp/jshelltemp2193900651454655061/6384782619469415234.edit >>> /tmp/jshelltemp2234949382818285124 >>> /tmp/jshelltemp2234949382818285124/4834457107790499447.edit >>> /tmp/jshelltemp2296337736965199344 >>> /tmp/jshelltemp2296337736965199344/8826222356240547610.edit >>> /tmp/jshelltemp2345658105656559252 >>> /tmp/jshelltemp2345658105656559252/6729333722014852729.edit >>> /tmp/jshelltemp2468675356543856110 >>> /tmp/jshelltemp2468675356543856110/6621846833826280297.edit >>> /tmp/jshelltemp2504345118557203640 >>> /tmp/jshelltemp2504345118557203640/5097858842709809254.edit >>> /tmp/jshelltemp2595239917647196066 >>> /tmp/jshelltemp2595239917647196066/4410162140727614450.edit >>> /tmp/jshelltemp2668148898346441797 >>> /tmp/jshelltemp2668148898346441797/1660414210153626169.edit >>> /tmp/jshelltemp3514984560124468983 >>> /tmp/jshelltemp3514984560124468983/6131864124091385623.edit >>> /tmp/jshelltemp3562125506660912173 >>> /tmp/jshelltemp3562125506660912173/8887290599369872073.edit >>> /tmp/jshelltemp40589362697391818 >>> /tmp/jshelltemp40589362697391818/8822906394660574353.edit >>> /tmp/jshelltemp4387371979722467975 >>> /tmp/jshelltemp4387371979722467975/7249033605230168031.edit >>> /tmp/jshelltemp4715020457318511491 >>> /tmp/jshelltemp4715020457318511491/4636728652227855346.edit >>> /tmp/jshelltemp52332485773094168 >>> /tmp/jshelltemp52332485773094168/1277048994347896757.edit >>> /tmp/jshelltemp5278128846699884471 >>> /tmp/jshelltemp5278128846699884471/44922152761642381.edit >>> /tmp/jshelltemp5320120409750616204 >>> /tmp/jshelltemp5320120409750616204/24459148772882266.edit >>> /tmp/jshelltemp5534152442553977652 >>> /tmp/jshelltemp5534152442553977652/8186176305757939505.edit >>> /tmp/jshelltemp5623564536996825207 >>> /tmp/jshelltemp5623564536996825207/9045016579988583399.edit >>> /tmp/jshelltemp5700044225140491973 >>> /tmp/jshelltemp5700044225140491973/3188060456352696621.edit >>> /tmp/jshelltemp6324874596657398893 >>> /tmp/jshelltemp6324874596657398893/3179325677151331223.edit >>> /tmp/jshelltemp6808171130698006683 >>> /tmp/jshelltemp6808171130698006683/319127357748973046.edit >>> /tmp/jshelltemp7001485162152525304 >>> /tmp/jshelltemp7001485162152525304/9168706811139870527.edit >>> /tmp/jshelltemp7069920922180135958 >>> /tmp/jshelltemp7069920922180135958/8686060872597749049.edit >>> /tmp/jshelltemp7088266688866808879 >>> /tmp/jshelltemp7088266688866808879/6924602628004312642.edit >>> /tmp/jshelltemp7173145703014422717 >>> /tmp/jshelltemp7173145703014422717/4607109423377503842.edit >>> /tmp/jshelltemp7180999435914656215 >>> /tmp/jshelltemp7180999435914656215/5549682196654974987.edit >>> /tmp/jshelltemp7208905856201817354 >>> /tmp/jshelltemp7208905856201817354/6181265411604183143.edit >>> /tmp/jshelltemp7680863956932965286 >>> /tmp/jshelltemp7680863956932965286/4077316136930888410.edit >>> /tmp/jshelltemp7853784893157006161 >>> /tmp/jshelltemp7853784893157006161/5787573000355892776.edit >>> /tmp/jshelltemp7992097935706702471 >>> /tmp/jshelltemp7992097935706702471/1856486408875906360.edit >>> /tmp/jshelltemp8128412259418228343 >>> /tmp/jshelltemp8128412259418228343/5002913207029300566.edit >>> /tmp/jshelltemp8227545996613827901 >>> /tmp/jshelltemp8227545996613827901/3843405868953231414.edit >>> /tmp/jshelltemp850631284448899163 >>> /tmp/jshelltemp850631284448899163/481600313656353994.edit >>> /tmp/jshelltemp8744516682365157187 >>> /tmp/jshelltemp8744516682365157187/5826738179758017666.edit >>> /tmp/jshelltemp8852008122297380391 >>> /tmp/jshelltemp8852008122297380391/3226693345657046477.edit >>> /tmp/jshelltemp9074215226291200769 >>> /tmp/jshelltemp9074215226291200769/8315526298738535034.edit >>> /tmp/jshelltemp9193145933675852815 >>> /tmp/jshelltemp9193145933675852815/8998940437928279313.edit >>> > From vicente.romero at oracle.com Tue Aug 2 14:48:43 2016 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Tue, 2 Aug 2016 10:48:43 -0400 Subject: jshell (tests?) leaking files in /tmp In-Reply-To: <57A0AEBC.7080204@oracle.com> References: <579BB20D.9060306@oracle.com> <1470138529.50728900@f28.i.mail.ru> <7b8db89f-6fc2-e1da-918c-2bcca05a2bb2@oracle.com> <57A0AEBC.7080204@oracle.com> Message-ID: <65e3315f-a485-1809-c417-a98441d6dfdd@oracle.com> On 08/02/2016 10:31 AM, Jonathan Gibbons wrote: > I think you can assume people will have write permission to /tmp, but > it is still bad practice to write files there and not clean them up > afterwards. I know it's a fair assumption but I remember having to fix tests because of this in my previous company, > > -- Jon Vicente > > On 08/02/2016 06:43 AM, Vicente-Arturo Romero-Zaldivar wrote: >> Hi, >> >> IMO, I don't think that it's a good practice to write files to the >> /tmp folder. Users with no write permission might have problems to >> run the tests. >> >> Thanks, >> Vicente >> >> On 08/02/2016 07:48 AM, Andrei Eremeev wrote: >>> Hi Jon, >>> As far as I remember, JShell uses temp files to edit code snippets >>> in external editors. And it looks like JShell does not remove the >>> files after editing. >>> -- >>> Andrei Eremeev Friday, 29 July 2016, 10:44PM +03:00 from Jonathan >>> Gibbons jonathan.gibbons at oracle.com : >>> >>>> My /tmp is accumulating jshell files: >>>> >>>> $ find /tmp/jshell* >>>> /tmp/jshelltemp1044549827386632150 >>>> /tmp/jshelltemp1044549827386632150/8011562224044845728.edit >>>> /tmp/jshelltemp1047969916921684187 >>>> /tmp/jshelltemp1047969916921684187/1740671090630915795.edit >>>> /tmp/jshelltemp1072678409055720780 >>>> /tmp/jshelltemp1072678409055720780/978408699063547197.edit >>>> /tmp/jshelltemp1200545436603537750 >>>> /tmp/jshelltemp1200545436603537750/3390705712185362355.edit >>>> /tmp/jshelltemp1221162966070216464 >>>> /tmp/jshelltemp1221162966070216464/3081222915116288162.edit >>>> /tmp/jshelltemp1425582075044687363 >>>> /tmp/jshelltemp1425582075044687363/4082709690184420251.edit >>>> /tmp/jshelltemp1577033095144892398 >>>> /tmp/jshelltemp1577033095144892398/9081427157952395244.edit >>>> /tmp/jshelltemp1585036544870564328 >>>> /tmp/jshelltemp1585036544870564328/3906837717961713151.edit >>>> /tmp/jshelltemp165895593330514486 >>>> /tmp/jshelltemp165895593330514486/6627843380470403643.edit >>>> /tmp/jshelltemp1833109810049396364 >>>> /tmp/jshelltemp1833109810049396364/517769421906389157.edit >>>> /tmp/jshelltemp2041981097096951060 >>>> /tmp/jshelltemp2041981097096951060/2349577263460706006.edit >>>> /tmp/jshelltemp2193900651454655061 >>>> /tmp/jshelltemp2193900651454655061/6384782619469415234.edit >>>> /tmp/jshelltemp2234949382818285124 >>>> /tmp/jshelltemp2234949382818285124/4834457107790499447.edit >>>> /tmp/jshelltemp2296337736965199344 >>>> /tmp/jshelltemp2296337736965199344/8826222356240547610.edit >>>> /tmp/jshelltemp2345658105656559252 >>>> /tmp/jshelltemp2345658105656559252/6729333722014852729.edit >>>> /tmp/jshelltemp2468675356543856110 >>>> /tmp/jshelltemp2468675356543856110/6621846833826280297.edit >>>> /tmp/jshelltemp2504345118557203640 >>>> /tmp/jshelltemp2504345118557203640/5097858842709809254.edit >>>> /tmp/jshelltemp2595239917647196066 >>>> /tmp/jshelltemp2595239917647196066/4410162140727614450.edit >>>> /tmp/jshelltemp2668148898346441797 >>>> /tmp/jshelltemp2668148898346441797/1660414210153626169.edit >>>> /tmp/jshelltemp3514984560124468983 >>>> /tmp/jshelltemp3514984560124468983/6131864124091385623.edit >>>> /tmp/jshelltemp3562125506660912173 >>>> /tmp/jshelltemp3562125506660912173/8887290599369872073.edit >>>> /tmp/jshelltemp40589362697391818 >>>> /tmp/jshelltemp40589362697391818/8822906394660574353.edit >>>> /tmp/jshelltemp4387371979722467975 >>>> /tmp/jshelltemp4387371979722467975/7249033605230168031.edit >>>> /tmp/jshelltemp4715020457318511491 >>>> /tmp/jshelltemp4715020457318511491/4636728652227855346.edit >>>> /tmp/jshelltemp52332485773094168 >>>> /tmp/jshelltemp52332485773094168/1277048994347896757.edit >>>> /tmp/jshelltemp5278128846699884471 >>>> /tmp/jshelltemp5278128846699884471/44922152761642381.edit >>>> /tmp/jshelltemp5320120409750616204 >>>> /tmp/jshelltemp5320120409750616204/24459148772882266.edit >>>> /tmp/jshelltemp5534152442553977652 >>>> /tmp/jshelltemp5534152442553977652/8186176305757939505.edit >>>> /tmp/jshelltemp5623564536996825207 >>>> /tmp/jshelltemp5623564536996825207/9045016579988583399.edit >>>> /tmp/jshelltemp5700044225140491973 >>>> /tmp/jshelltemp5700044225140491973/3188060456352696621.edit >>>> /tmp/jshelltemp6324874596657398893 >>>> /tmp/jshelltemp6324874596657398893/3179325677151331223.edit >>>> /tmp/jshelltemp6808171130698006683 >>>> /tmp/jshelltemp6808171130698006683/319127357748973046.edit >>>> /tmp/jshelltemp7001485162152525304 >>>> /tmp/jshelltemp7001485162152525304/9168706811139870527.edit >>>> /tmp/jshelltemp7069920922180135958 >>>> /tmp/jshelltemp7069920922180135958/8686060872597749049.edit >>>> /tmp/jshelltemp7088266688866808879 >>>> /tmp/jshelltemp7088266688866808879/6924602628004312642.edit >>>> /tmp/jshelltemp7173145703014422717 >>>> /tmp/jshelltemp7173145703014422717/4607109423377503842.edit >>>> /tmp/jshelltemp7180999435914656215 >>>> /tmp/jshelltemp7180999435914656215/5549682196654974987.edit >>>> /tmp/jshelltemp7208905856201817354 >>>> /tmp/jshelltemp7208905856201817354/6181265411604183143.edit >>>> /tmp/jshelltemp7680863956932965286 >>>> /tmp/jshelltemp7680863956932965286/4077316136930888410.edit >>>> /tmp/jshelltemp7853784893157006161 >>>> /tmp/jshelltemp7853784893157006161/5787573000355892776.edit >>>> /tmp/jshelltemp7992097935706702471 >>>> /tmp/jshelltemp7992097935706702471/1856486408875906360.edit >>>> /tmp/jshelltemp8128412259418228343 >>>> /tmp/jshelltemp8128412259418228343/5002913207029300566.edit >>>> /tmp/jshelltemp8227545996613827901 >>>> /tmp/jshelltemp8227545996613827901/3843405868953231414.edit >>>> /tmp/jshelltemp850631284448899163 >>>> /tmp/jshelltemp850631284448899163/481600313656353994.edit >>>> /tmp/jshelltemp8744516682365157187 >>>> /tmp/jshelltemp8744516682365157187/5826738179758017666.edit >>>> /tmp/jshelltemp8852008122297380391 >>>> /tmp/jshelltemp8852008122297380391/3226693345657046477.edit >>>> /tmp/jshelltemp9074215226291200769 >>>> /tmp/jshelltemp9074215226291200769/8315526298738535034.edit >>>> /tmp/jshelltemp9193145933675852815 >>>> /tmp/jshelltemp9193145933675852815/8998940437928279313.edit >>>> >> > From jonathan.gibbons at oracle.com Tue Aug 2 17:22:29 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 02 Aug 2016 10:22:29 -0700 Subject: jshell (tests?) leaking files in /tmp In-Reply-To: <57A0D53B.6020706@oracle.com> References: <579BB20D.9060306@oracle.com> <1470138529.50728900@f28.i.mail.ru> <7b8db89f-6fc2-e1da-918c-2bcca05a2bb2@oracle.com> <57A0AEBC.7080204@oracle.com> <65e3315f-a485-1809-c417-a98441d6dfdd@oracle.com> <57A0D53B.6020706@oracle.com> Message-ID: <57A0D6D5.4090408@oracle.com> I cleaned out my /tmp directory last week, and the /tmp/jshelltemp* files are back again -- Jon On 08/02/2016 10:15 AM, Michel Trudeau wrote: > As a reference point, I don't see these in my /tmp directory, on OS/X. > > But regardless, we should file a bug. > > Thanks, > Michel > > > > > > Vicente-Arturo Romero-Zaldivar wrote: >> On 08/02/2016 10:31 AM, Jonathan Gibbons wrote: >>> I think you can assume people will have write permission to /tmp, >>> but it is still bad practice to write files there and not clean them >>> up afterwards. >> >> I know it's a fair assumption but I remember having to fix tests >> because of this in my previous company, >> >>> >>> -- Jon >> >> Vicente >> >>> >>> On 08/02/2016 06:43 AM, Vicente-Arturo Romero-Zaldivar wrote: >>>> Hi, >>>> >>>> IMO, I don't think that it's a good practice to write files to the >>>> /tmp folder. Users with no write permission might have problems to >>>> run the tests. >>>> >>>> Thanks, >>>> Vicente >>>> >>>> On 08/02/2016 07:48 AM, Andrei Eremeev wrote: >>>>> Hi Jon, >>>>> As far as I remember, JShell uses temp files to edit code snippets >>>>> in external editors. And it looks like JShell does not remove the >>>>> files after editing. >>>>> -- >>>>> Andrei Eremeev Friday, 29 July 2016, 10:44PM +03:00 from Jonathan >>>>> Gibbons jonathan.gibbons at oracle.com : >>>>> >>>>>> My /tmp is accumulating jshell files: >>>>>> >>>>>> $ find /tmp/jshell* >>>>>> /tmp/jshelltemp1044549827386632150 >>>>>> /tmp/jshelltemp1044549827386632150/8011562224044845728.edit >>>>>> /tmp/jshelltemp1047969916921684187 >>>>>> /tmp/jshelltemp1047969916921684187/1740671090630915795.edit >>>>>> /tmp/jshelltemp1072678409055720780 >>>>>> /tmp/jshelltemp1072678409055720780/978408699063547197.edit >>>>>> /tmp/jshelltemp1200545436603537750 >>>>>> /tmp/jshelltemp1200545436603537750/3390705712185362355.edit >>>>>> /tmp/jshelltemp1221162966070216464 >>>>>> /tmp/jshelltemp1221162966070216464/3081222915116288162.edit >>>>>> /tmp/jshelltemp1425582075044687363 >>>>>> /tmp/jshelltemp1425582075044687363/4082709690184420251.edit >>>>>> /tmp/jshelltemp1577033095144892398 >>>>>> /tmp/jshelltemp1577033095144892398/9081427157952395244.edit >>>>>> /tmp/jshelltemp1585036544870564328 >>>>>> /tmp/jshelltemp1585036544870564328/3906837717961713151.edit >>>>>> /tmp/jshelltemp165895593330514486 >>>>>> /tmp/jshelltemp165895593330514486/6627843380470403643.edit >>>>>> /tmp/jshelltemp1833109810049396364 >>>>>> /tmp/jshelltemp1833109810049396364/517769421906389157.edit >>>>>> /tmp/jshelltemp2041981097096951060 >>>>>> /tmp/jshelltemp2041981097096951060/2349577263460706006.edit >>>>>> /tmp/jshelltemp2193900651454655061 >>>>>> /tmp/jshelltemp2193900651454655061/6384782619469415234.edit >>>>>> /tmp/jshelltemp2234949382818285124 >>>>>> /tmp/jshelltemp2234949382818285124/4834457107790499447.edit >>>>>> /tmp/jshelltemp2296337736965199344 >>>>>> /tmp/jshelltemp2296337736965199344/8826222356240547610.edit >>>>>> /tmp/jshelltemp2345658105656559252 >>>>>> /tmp/jshelltemp2345658105656559252/6729333722014852729.edit >>>>>> /tmp/jshelltemp2468675356543856110 >>>>>> /tmp/jshelltemp2468675356543856110/6621846833826280297.edit >>>>>> /tmp/jshelltemp2504345118557203640 >>>>>> /tmp/jshelltemp2504345118557203640/5097858842709809254.edit >>>>>> /tmp/jshelltemp2595239917647196066 >>>>>> /tmp/jshelltemp2595239917647196066/4410162140727614450.edit >>>>>> /tmp/jshelltemp2668148898346441797 >>>>>> /tmp/jshelltemp2668148898346441797/1660414210153626169.edit >>>>>> /tmp/jshelltemp3514984560124468983 >>>>>> /tmp/jshelltemp3514984560124468983/6131864124091385623.edit >>>>>> /tmp/jshelltemp3562125506660912173 >>>>>> /tmp/jshelltemp3562125506660912173/8887290599369872073.edit >>>>>> /tmp/jshelltemp40589362697391818 >>>>>> /tmp/jshelltemp40589362697391818/8822906394660574353.edit >>>>>> /tmp/jshelltemp4387371979722467975 >>>>>> /tmp/jshelltemp4387371979722467975/7249033605230168031.edit >>>>>> /tmp/jshelltemp4715020457318511491 >>>>>> /tmp/jshelltemp4715020457318511491/4636728652227855346.edit >>>>>> /tmp/jshelltemp52332485773094168 >>>>>> /tmp/jshelltemp52332485773094168/1277048994347896757.edit >>>>>> /tmp/jshelltemp5278128846699884471 >>>>>> /tmp/jshelltemp5278128846699884471/44922152761642381.edit >>>>>> /tmp/jshelltemp5320120409750616204 >>>>>> /tmp/jshelltemp5320120409750616204/24459148772882266.edit >>>>>> /tmp/jshelltemp5534152442553977652 >>>>>> /tmp/jshelltemp5534152442553977652/8186176305757939505.edit >>>>>> /tmp/jshelltemp5623564536996825207 >>>>>> /tmp/jshelltemp5623564536996825207/9045016579988583399.edit >>>>>> /tmp/jshelltemp5700044225140491973 >>>>>> /tmp/jshelltemp5700044225140491973/3188060456352696621.edit >>>>>> /tmp/jshelltemp6324874596657398893 >>>>>> /tmp/jshelltemp6324874596657398893/3179325677151331223.edit >>>>>> /tmp/jshelltemp6808171130698006683 >>>>>> /tmp/jshelltemp6808171130698006683/319127357748973046.edit >>>>>> /tmp/jshelltemp7001485162152525304 >>>>>> /tmp/jshelltemp7001485162152525304/9168706811139870527.edit >>>>>> /tmp/jshelltemp7069920922180135958 >>>>>> /tmp/jshelltemp7069920922180135958/8686060872597749049.edit >>>>>> /tmp/jshelltemp7088266688866808879 >>>>>> /tmp/jshelltemp7088266688866808879/6924602628004312642.edit >>>>>> /tmp/jshelltemp7173145703014422717 >>>>>> /tmp/jshelltemp7173145703014422717/4607109423377503842.edit >>>>>> /tmp/jshelltemp7180999435914656215 >>>>>> /tmp/jshelltemp7180999435914656215/5549682196654974987.edit >>>>>> /tmp/jshelltemp7208905856201817354 >>>>>> /tmp/jshelltemp7208905856201817354/6181265411604183143.edit >>>>>> /tmp/jshelltemp7680863956932965286 >>>>>> /tmp/jshelltemp7680863956932965286/4077316136930888410.edit >>>>>> /tmp/jshelltemp7853784893157006161 >>>>>> /tmp/jshelltemp7853784893157006161/5787573000355892776.edit >>>>>> /tmp/jshelltemp7992097935706702471 >>>>>> /tmp/jshelltemp7992097935706702471/1856486408875906360.edit >>>>>> /tmp/jshelltemp8128412259418228343 >>>>>> /tmp/jshelltemp8128412259418228343/5002913207029300566.edit >>>>>> /tmp/jshelltemp8227545996613827901 >>>>>> /tmp/jshelltemp8227545996613827901/3843405868953231414.edit >>>>>> /tmp/jshelltemp850631284448899163 >>>>>> /tmp/jshelltemp850631284448899163/481600313656353994.edit >>>>>> /tmp/jshelltemp8744516682365157187 >>>>>> /tmp/jshelltemp8744516682365157187/5826738179758017666.edit >>>>>> /tmp/jshelltemp8852008122297380391 >>>>>> /tmp/jshelltemp8852008122297380391/3226693345657046477.edit >>>>>> /tmp/jshelltemp9074215226291200769 >>>>>> /tmp/jshelltemp9074215226291200769/8315526298738535034.edit >>>>>> /tmp/jshelltemp9193145933675852815 >>>>>> /tmp/jshelltemp9193145933675852815/8998940437928279313.edit >>>>>> >>>> >>> >> > From jonathan.gibbons at oracle.com Tue Aug 2 17:37:56 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 02 Aug 2016 10:37:56 -0700 Subject: jshell (tests?) leaking files in /tmp In-Reply-To: <57A0D6D5.4090408@oracle.com> References: <579BB20D.9060306@oracle.com> <1470138529.50728900@f28.i.mail.ru> <7b8db89f-6fc2-e1da-918c-2bcca05a2bb2@oracle.com> <57A0AEBC.7080204@oracle.com> <65e3315f-a485-1809-c417-a98441d6dfdd@oracle.com> <57A0D53B.6020706@oracle.com> <57A0D6D5.4090408@oracle.com> Message-ID: <57A0DA74.50709@oracle.com> A simple script to execute the jshell tests one at a time, and to check the /tmp directory after executing each test, shows that the culprit is ToolretainTest.java I'll file a bug. -- Jon On 08/02/2016 10:22 AM, Jonathan Gibbons wrote: > I cleaned out my /tmp directory last week, and the /tmp/jshelltemp* > files are back again > > -- Jon > > On 08/02/2016 10:15 AM, Michel Trudeau wrote: >> As a reference point, I don't see these in my /tmp directory, on OS/X. >> >> But regardless, we should file a bug. >> >> Thanks, >> Michel >> >> >> >> >> >> Vicente-Arturo Romero-Zaldivar wrote: >>> On 08/02/2016 10:31 AM, Jonathan Gibbons wrote: >>>> I think you can assume people will have write permission to /tmp, >>>> but it is still bad practice to write files there and not clean >>>> them up afterwards. >>> >>> I know it's a fair assumption but I remember having to fix tests >>> because of this in my previous company, >>> >>>> >>>> -- Jon >>> >>> Vicente >>> >>>> >>>> On 08/02/2016 06:43 AM, Vicente-Arturo Romero-Zaldivar wrote: >>>>> Hi, >>>>> >>>>> IMO, I don't think that it's a good practice to write files to the >>>>> /tmp folder. Users with no write permission might have problems to >>>>> run the tests. >>>>> >>>>> Thanks, >>>>> Vicente >>>>> >>>>> On 08/02/2016 07:48 AM, Andrei Eremeev wrote: >>>>>> Hi Jon, >>>>>> As far as I remember, JShell uses temp files to edit code >>>>>> snippets in external editors. And it looks like JShell does not >>>>>> remove the files after editing. >>>>>> -- >>>>>> Andrei Eremeev Friday, 29 July 2016, 10:44PM +03:00 from Jonathan >>>>>> Gibbons jonathan.gibbons at oracle.com : >>>>>> >>>>>>> My /tmp is accumulating jshell files: >>>>>>> >>>>>>> $ find /tmp/jshell* >>>>>>> /tmp/jshelltemp1044549827386632150 >>>>>>> /tmp/jshelltemp1044549827386632150/8011562224044845728.edit >>>>>>> /tmp/jshelltemp1047969916921684187 >>>>>>> /tmp/jshelltemp1047969916921684187/1740671090630915795.edit >>>>>>> /tmp/jshelltemp1072678409055720780 >>>>>>> /tmp/jshelltemp1072678409055720780/978408699063547197.edit >>>>>>> /tmp/jshelltemp1200545436603537750 >>>>>>> /tmp/jshelltemp1200545436603537750/3390705712185362355.edit >>>>>>> /tmp/jshelltemp1221162966070216464 >>>>>>> /tmp/jshelltemp1221162966070216464/3081222915116288162.edit >>>>>>> /tmp/jshelltemp1425582075044687363 >>>>>>> /tmp/jshelltemp1425582075044687363/4082709690184420251.edit >>>>>>> /tmp/jshelltemp1577033095144892398 >>>>>>> /tmp/jshelltemp1577033095144892398/9081427157952395244.edit >>>>>>> /tmp/jshelltemp1585036544870564328 >>>>>>> /tmp/jshelltemp1585036544870564328/3906837717961713151.edit >>>>>>> /tmp/jshelltemp165895593330514486 >>>>>>> /tmp/jshelltemp165895593330514486/6627843380470403643.edit >>>>>>> /tmp/jshelltemp1833109810049396364 >>>>>>> /tmp/jshelltemp1833109810049396364/517769421906389157.edit >>>>>>> /tmp/jshelltemp2041981097096951060 >>>>>>> /tmp/jshelltemp2041981097096951060/2349577263460706006.edit >>>>>>> /tmp/jshelltemp2193900651454655061 >>>>>>> /tmp/jshelltemp2193900651454655061/6384782619469415234.edit >>>>>>> /tmp/jshelltemp2234949382818285124 >>>>>>> /tmp/jshelltemp2234949382818285124/4834457107790499447.edit >>>>>>> /tmp/jshelltemp2296337736965199344 >>>>>>> /tmp/jshelltemp2296337736965199344/8826222356240547610.edit >>>>>>> /tmp/jshelltemp2345658105656559252 >>>>>>> /tmp/jshelltemp2345658105656559252/6729333722014852729.edit >>>>>>> /tmp/jshelltemp2468675356543856110 >>>>>>> /tmp/jshelltemp2468675356543856110/6621846833826280297.edit >>>>>>> /tmp/jshelltemp2504345118557203640 >>>>>>> /tmp/jshelltemp2504345118557203640/5097858842709809254.edit >>>>>>> /tmp/jshelltemp2595239917647196066 >>>>>>> /tmp/jshelltemp2595239917647196066/4410162140727614450.edit >>>>>>> /tmp/jshelltemp2668148898346441797 >>>>>>> /tmp/jshelltemp2668148898346441797/1660414210153626169.edit >>>>>>> /tmp/jshelltemp3514984560124468983 >>>>>>> /tmp/jshelltemp3514984560124468983/6131864124091385623.edit >>>>>>> /tmp/jshelltemp3562125506660912173 >>>>>>> /tmp/jshelltemp3562125506660912173/8887290599369872073.edit >>>>>>> /tmp/jshelltemp40589362697391818 >>>>>>> /tmp/jshelltemp40589362697391818/8822906394660574353.edit >>>>>>> /tmp/jshelltemp4387371979722467975 >>>>>>> /tmp/jshelltemp4387371979722467975/7249033605230168031.edit >>>>>>> /tmp/jshelltemp4715020457318511491 >>>>>>> /tmp/jshelltemp4715020457318511491/4636728652227855346.edit >>>>>>> /tmp/jshelltemp52332485773094168 >>>>>>> /tmp/jshelltemp52332485773094168/1277048994347896757.edit >>>>>>> /tmp/jshelltemp5278128846699884471 >>>>>>> /tmp/jshelltemp5278128846699884471/44922152761642381.edit >>>>>>> /tmp/jshelltemp5320120409750616204 >>>>>>> /tmp/jshelltemp5320120409750616204/24459148772882266.edit >>>>>>> /tmp/jshelltemp5534152442553977652 >>>>>>> /tmp/jshelltemp5534152442553977652/8186176305757939505.edit >>>>>>> /tmp/jshelltemp5623564536996825207 >>>>>>> /tmp/jshelltemp5623564536996825207/9045016579988583399.edit >>>>>>> /tmp/jshelltemp5700044225140491973 >>>>>>> /tmp/jshelltemp5700044225140491973/3188060456352696621.edit >>>>>>> /tmp/jshelltemp6324874596657398893 >>>>>>> /tmp/jshelltemp6324874596657398893/3179325677151331223.edit >>>>>>> /tmp/jshelltemp6808171130698006683 >>>>>>> /tmp/jshelltemp6808171130698006683/319127357748973046.edit >>>>>>> /tmp/jshelltemp7001485162152525304 >>>>>>> /tmp/jshelltemp7001485162152525304/9168706811139870527.edit >>>>>>> /tmp/jshelltemp7069920922180135958 >>>>>>> /tmp/jshelltemp7069920922180135958/8686060872597749049.edit >>>>>>> /tmp/jshelltemp7088266688866808879 >>>>>>> /tmp/jshelltemp7088266688866808879/6924602628004312642.edit >>>>>>> /tmp/jshelltemp7173145703014422717 >>>>>>> /tmp/jshelltemp7173145703014422717/4607109423377503842.edit >>>>>>> /tmp/jshelltemp7180999435914656215 >>>>>>> /tmp/jshelltemp7180999435914656215/5549682196654974987.edit >>>>>>> /tmp/jshelltemp7208905856201817354 >>>>>>> /tmp/jshelltemp7208905856201817354/6181265411604183143.edit >>>>>>> /tmp/jshelltemp7680863956932965286 >>>>>>> /tmp/jshelltemp7680863956932965286/4077316136930888410.edit >>>>>>> /tmp/jshelltemp7853784893157006161 >>>>>>> /tmp/jshelltemp7853784893157006161/5787573000355892776.edit >>>>>>> /tmp/jshelltemp7992097935706702471 >>>>>>> /tmp/jshelltemp7992097935706702471/1856486408875906360.edit >>>>>>> /tmp/jshelltemp8128412259418228343 >>>>>>> /tmp/jshelltemp8128412259418228343/5002913207029300566.edit >>>>>>> /tmp/jshelltemp8227545996613827901 >>>>>>> /tmp/jshelltemp8227545996613827901/3843405868953231414.edit >>>>>>> /tmp/jshelltemp850631284448899163 >>>>>>> /tmp/jshelltemp850631284448899163/481600313656353994.edit >>>>>>> /tmp/jshelltemp8744516682365157187 >>>>>>> /tmp/jshelltemp8744516682365157187/5826738179758017666.edit >>>>>>> /tmp/jshelltemp8852008122297380391 >>>>>>> /tmp/jshelltemp8852008122297380391/3226693345657046477.edit >>>>>>> /tmp/jshelltemp9074215226291200769 >>>>>>> /tmp/jshelltemp9074215226291200769/8315526298738535034.edit >>>>>>> /tmp/jshelltemp9193145933675852815 >>>>>>> /tmp/jshelltemp9193145933675852815/8998940437928279313.edit >>>>>>> >>>>> >>>> >>> >> > From jonathan.gibbons at oracle.com Tue Aug 2 17:43:25 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 02 Aug 2016 10:43:25 -0700 Subject: jshell (tests?) leaking files in /tmp In-Reply-To: <57A0DA74.50709@oracle.com> References: <579BB20D.9060306@oracle.com> <1470138529.50728900@f28.i.mail.ru> <7b8db89f-6fc2-e1da-918c-2bcca05a2bb2@oracle.com> <57A0AEBC.7080204@oracle.com> <65e3315f-a485-1809-c417-a98441d6dfdd@oracle.com> <57A0D53B.6020706@oracle.com> <57A0D6D5.4090408@oracle.com> <57A0DA74.50709@oracle.com> Message-ID: <57A0DBBD.6070205@oracle.com> On 08/02/2016 10:37 AM, Jonathan Gibbons wrote: > A simple script to execute the jshell tests one at a time, and to > check the /tmp directory after executing each test, shows that the > culprit is ToolretainTest.java > > I'll file a bug. > > -- Jon https://bugs.openjdk.java.net/browse/JDK-8162989 From andrei.i.eremeev at mail.ru Tue Aug 2 20:03:07 2016 From: andrei.i.eremeev at mail.ru (=?UTF-8?B?QW5kcmVpIEVyZW1lZXY=?=) Date: Tue, 02 Aug 2016 23:03:07 +0300 Subject: =?UTF-8?B?UmVbMl06IGpzaGVsbCAodGVzdHM/KSBsZWFraW5nIGZpbGVzIGluIC90bXA=?= In-Reply-To: <57A0DBBD.6070205@oracle.com> References: <579BB20D.9060306@oracle.com> <57A0DA74.50709@oracle.com> <57A0DBBD.6070205@oracle.com> Message-ID: <1470168187.885904628@f209.i.mail.ru> According to source code of JShell, a new temp file is created in ExternalEditor when a code snippet is modified. jdk.internal.jshell.tool.ExternalEditor.java: method setupWatch: ??? this.dir = Files.createTempDirectory("jshelltemp"); ??? this.tmpfile = Files.createTempFile(dir, null, ".edit"); The created file is not removed. I reproduced the problem with vim: int h = 10; /set editor vim /edit h A file is created in tmp if /edit is executed. Best regards, Andrei Eremeev >Tuesday, August 2, 2016 8:43 PM +03:00 from Jonathan Gibbons : > > > >On 08/02/2016 10:37 AM, Jonathan Gibbons wrote: >> A simple script to execute the jshell tests one at a time, and to >> check the /tmp directory after executing each test, shows that the >> culprit is ToolretainTest.java >> >> I'll file a bug. >> >> -- Jon >https://bugs.openjdk.java.net/browse/JDK-8162989 From jonathan.gibbons at oracle.com Tue Aug 2 20:12:59 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 02 Aug 2016 13:12:59 -0700 Subject: jshell (tests?) leaking files in /tmp In-Reply-To: <1470168187.885904628@f209.i.mail.ru> References: <579BB20D.9060306@oracle.com> <57A0DA74.50709@oracle.com> <57A0DBBD.6070205@oracle.com> <1470168187.885904628@f209.i.mail.ru> Message-ID: <57A0FECB.3040000@oracle.com> I note that Files.createTempDirectory says this: > As with the |createTempFile| methods, this method is only part of a > temporary-file facility. A |shutdown-hook| > , > or the |File.deleteOnExit()| > > mechanism may be used to delete the directory automatically. That being said, it would think it is better to avoid using Files.createTempDirectory, and to then use the favor of createTempFile that creates files directly in the default temporary directory, and to explicitly delete the file when it is no longer required. public staticPath createTempFile(String prefix, String suffix, FileAttribute ... attrs) throwsIOException -- Jon On 08/02/2016 01:03 PM, Andrei Eremeev wrote: > According to source code of JShell, a new temp file is created in ExternalEditor when a code snippet is modified. > > jdk.internal.jshell.tool.ExternalEditor.java: > method setupWatch: > this.dir = Files.createTempDirectory("jshelltemp"); > this.tmpfile = Files.createTempFile(dir, null, ".edit"); > > The created file is not removed. > > I reproduced the problem with vim: > int h = 10; > /set editor vim > /edit h > > A file is created in tmp if /edit is executed. > > Best regards, > Andrei Eremeev > >> Tuesday, August 2, 2016 8:43 PM +03:00 from Jonathan Gibbons : >> >> >> >> On 08/02/2016 10:37 AM, Jonathan Gibbons wrote: >>> A simple script to execute the jshell tests one at a time, and to >>> check the /tmp directory after executing each test, shows that the >>> culprit is ToolretainTest.java >>> >>> I'll file a bug. >>> >>> -- Jon >> https://bugs.openjdk.java.net/browse/JDK-8162989 From robert.field at oracle.com Tue Aug 9 06:15:31 2016 From: robert.field at oracle.com (Robert Field) Date: Mon, 08 Aug 2016 23:15:31 -0700 Subject: RFR 8143964: JShell API: convert query responses to Stream instead of List/Collection Message-ID: <57A97503.9020906@oracle.com> Please review this deferred API review request. Basically changing List<*> return to Stream<*> return for seven methods: Stream snippets() Stream variables() Stream methods() Stream types() Stream imports() Stream diagnostics(Snippet snippet) Stream unresolvedDependencies(DeclarationSnippet snippet) Bug: https://bugs.openjdk.java.net/browse/JDK-8143964 Webrev: http://cr.openjdk.java.net/~rfield/8143964v0.webrev/ Spec: http://cr.openjdk.java.net/~rfield/8143964v0.jshellAPI/jdk/jshell/JShell.html Specdiff: http://cr.openjdk.java.net/~rfield/8143964v0.specdiff/jdk/jshell/JShell.html Thanks, Robert From robert.field at oracle.com Tue Aug 9 17:10:23 2016 From: robert.field at oracle.com (Robert Field) Date: Tue, 09 Aug 2016 10:10:23 -0700 Subject: RFR(xs) 8163500: JShell: ProblemList.txt update: 8139872 and 8080843 fixed Message-ID: <57AA0E7F.1060600@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8163500 Diff: --- a/test/ProblemList.txt Mon Aug 08 11:48:02 2016 -0700 +++ b/test/ProblemList.txt Tue Aug 09 10:04:46 2016 -0700 @@ -54,8 +54,6 @@ # # jshell -jdk/jshell/EditorPadTest.java 8139872 generic-all test requires a non-headless environment -jdk/jshell/ExternalEditorTest.java 8080843 generic-all invalid key error occurs when external editor is used. jdk/jshell/ToolBasicTest.java 8139873 generic-all JShell tests failing ########################################################################### Referenced bugs: https://bugs.openjdk.java.net/browse/JDK-8139872 https://bugs.openjdk.java.net/browse/JDK-8080843 Thanks, Robert From paul.sandoz at oracle.com Tue Aug 9 20:04:56 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 9 Aug 2016 13:04:56 -0700 Subject: RFR 8143964: JShell API: convert query responses to Stream instead of List/Collection In-Reply-To: <57A97503.9020906@oracle.com> References: <57A97503.9020906@oracle.com> Message-ID: Hi, Looks ok, just some minor stuff. JShellTool ? 1027 Stream dropableSnippets() { 1028 return state.snippets() 1029 .filter(sn -> state.status(sn).isActive() && sn instanceof PersistentSnippet) 1030 .map(sn -> (PersistentSnippet) sn); 1031 } Not sure if you can do PersistentSnippet.class::cast, if so up to you. 1895 Stream sns = at.hasOption("-all") 1896 ? state.snippets() 1897 : state.snippets().filter(this::mainActive); 1898 Iterator it = sns.iterator(); 1899 while (it.hasNext()) { 1900 Snippet sn = it.next(); 1901 writer.write(sn.source()); 1902 writer.write("\n"); 1903 } You can use forEach instead of an iterator. Paul. > On 8 Aug 2016, at 23:15, Robert Field wrote: > > Please review this deferred API review request. > Basically changing List<*> return to Stream<*> return for seven methods: > Stream snippets() > Stream variables() > Stream methods() > Stream types() > Stream imports() > Stream diagnostics(Snippet snippet) > Stream unresolvedDependencies(DeclarationSnippet snippet) > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8143964 > > Webrev: > http://cr.openjdk.java.net/~rfield/8143964v0.webrev/ > > Spec: > http://cr.openjdk.java.net/~rfield/8143964v0.jshellAPI/jdk/jshell/JShell.html > > Specdiff: > http://cr.openjdk.java.net/~rfield/8143964v0.specdiff/jdk/jshell/JShell.html > > Thanks, > Robert > From robert.field at oracle.com Tue Aug 9 20:24:02 2016 From: robert.field at oracle.com (Robert Field) Date: Tue, 09 Aug 2016 13:24:02 -0700 Subject: RFR 8143964: JShell API: convert query responses to Stream instead of List/Collection In-Reply-To: References: <57A97503.9020906@oracle.com> Message-ID: <57AA3BE2.8090502@oracle.com> On 08/09/16 13:04, Paul Sandoz wrote: > Hi, > > Looks ok, just some minor stuff. Thanks, Paul, for the review. See below. > > > JShellTool > ? > > 1027 Stream dropableSnippets() { > 1028 return state.snippets() > 1029 .filter(sn -> state.status(sn).isActive() && sn instanceof PersistentSnippet) > 1030 .map(sn -> (PersistentSnippet) sn); > 1031 } > > > Not sure if you can do PersistentSnippet.class::cast, if so up to you. Is that preferred? > > > 1895 Stream sns = at.hasOption("-all") > 1896 ? state.snippets() > 1897 : state.snippets().filter(this::mainActive); > 1898 Iterator it = sns.iterator(); > 1899 while (it.hasNext()) { > 1900 Snippet sn = it.next(); > 1901 writer.write(sn.source()); > 1902 writer.write("\n"); > 1903 } > > You can use forEach instead of an iterator. Actually, the "write" can thrown IOException. Thanks, Robert > > Paul. > >> On 8 Aug 2016, at 23:15, Robert Field wrote: >> >> Please review this deferred API review request. >> Basically changing List<*> return to Stream<*> return for seven methods: >> Stream snippets() >> Stream variables() >> Stream methods() >> Stream types() >> Stream imports() >> Stream diagnostics(Snippet snippet) >> Stream unresolvedDependencies(DeclarationSnippet snippet) >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8143964 >> >> Webrev: >> http://cr.openjdk.java.net/~rfield/8143964v0.webrev/ >> >> Spec: >> http://cr.openjdk.java.net/~rfield/8143964v0.jshellAPI/jdk/jshell/JShell.html >> >> Specdiff: >> http://cr.openjdk.java.net/~rfield/8143964v0.specdiff/jdk/jshell/JShell.html >> >> Thanks, >> Robert >> From paul.sandoz at oracle.com Tue Aug 9 20:34:13 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 9 Aug 2016 13:34:13 -0700 Subject: RFR 8143964: JShell API: convert query responses to Stream instead of List/Collection In-Reply-To: <57AA3BE2.8090502@oracle.com> References: <57A97503.9020906@oracle.com> <57AA3BE2.8090502@oracle.com> Message-ID: <672567E4-6683-447D-9499-AB311069ED21@oracle.com> > On 9 Aug 2016, at 13:24, Robert Field wrote: > > > On 08/09/16 13:04, Paul Sandoz wrote: >> Hi, >> >> Looks ok, just some minor stuff. > > Thanks, Paul, for the review. See below. >> >> >> JShellTool >> ? >> >> 1027 Stream dropableSnippets() { >> 1028 return state.snippets() >> 1029 .filter(sn -> state.status(sn).isActive() && sn instanceof PersistentSnippet) >> 1030 .map(sn -> (PersistentSnippet) sn); >> 1031 } >> >> >> Not sure if you can do PersistentSnippet.class::cast, if so up to you. > > Is that preferred? > It?s subjective, I might prefer it :-) it was just a suggestion if you prefer it. >> >> >> 1895 Stream sns = at.hasOption("-all") >> 1896 ? state.snippets() >> 1897 : state.snippets().filter(this::mainActive); >> 1898 Iterator it = sns.iterator(); >> 1899 while (it.hasNext()) { >> 1900 Snippet sn = it.next(); >> 1901 writer.write(sn.source()); >> 1902 writer.write("\n"); >> 1903 } >> >> You can use forEach instead of an iterator. > > Actually, the "write" can thrown IOException. > Ah, ok, i missed that. Paul. From robert.field at oracle.com Tue Aug 9 21:49:05 2016 From: robert.field at oracle.com (Robert Field) Date: Tue, 09 Aug 2016 14:49:05 -0700 Subject: RFR 8143964: JShell API: convert query responses to Stream instead of List/Collection In-Reply-To: <672567E4-6683-447D-9499-AB311069ED21@oracle.com> References: <57A97503.9020906@oracle.com> <57AA3BE2.8090502@oracle.com> <672567E4-6683-447D-9499-AB311069ED21@oracle.com> Message-ID: <57AA4FD1.6060605@oracle.com> Thumbs up? -Robert On 08/09/16 13:34, Paul Sandoz wrote: >> On 9 Aug 2016, at 13:24, Robert Field wrote: >> >> >> On 08/09/16 13:04, Paul Sandoz wrote: >>> Hi, >>> >>> Looks ok, just some minor stuff. >> Thanks, Paul, for the review. See below. >>> >>> JShellTool >>> ? >>> >>> 1027 Stream dropableSnippets() { >>> 1028 return state.snippets() >>> 1029 .filter(sn -> state.status(sn).isActive() && sn instanceof PersistentSnippet) >>> 1030 .map(sn -> (PersistentSnippet) sn); >>> 1031 } >>> >>> >>> Not sure if you can do PersistentSnippet.class::cast, if so up to you. >> Is that preferred? >> > It?s subjective, I might prefer it :-) it was just a suggestion if you prefer it. > > >>> >>> 1895 Stream sns = at.hasOption("-all") >>> 1896 ? state.snippets() >>> 1897 : state.snippets().filter(this::mainActive); >>> 1898 Iterator it = sns.iterator(); >>> 1899 while (it.hasNext()) { >>> 1900 Snippet sn = it.next(); >>> 1901 writer.write(sn.source()); >>> 1902 writer.write("\n"); >>> 1903 } >>> >>> You can use forEach instead of an iterator. >> Actually, the "write" can thrown IOException. >> > Ah, ok, i missed that. > > Paul. From paul.sandoz at oracle.com Tue Aug 9 21:58:50 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 9 Aug 2016 14:58:50 -0700 Subject: RFR 8143964: JShell API: convert query responses to Stream instead of List/Collection In-Reply-To: <57AA4FD1.6060605@oracle.com> References: <57A97503.9020906@oracle.com> <57AA3BE2.8090502@oracle.com> <672567E4-6683-447D-9499-AB311069ED21@oracle.com> <57AA4FD1.6060605@oracle.com> Message-ID: <82D76278-9682-440A-8B0F-480251BCF1FF@oracle.com> > On 9 Aug 2016, at 14:49, Robert Field wrote: > > Thumbs up? > Yes, +1 Paul. From bitterfoxc at gmail.com Tue Aug 9 23:37:50 2016 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Wed, 10 Aug 2016 08:37:50 +0900 Subject: RFR 8143964: JShell API: convert query responses to Stream instead of List/Collection In-Reply-To: <57A97503.9020906@oracle.com> References: <57A97503.9020906@oracle.com> Message-ID: Hi, Robert, I have 2 comments: 1895 Stream sns = at.hasOption("-all") 1896 ? state.snippets() 1897 : state.snippets().filter(this::mainActive); 1898 Iterator it = sns.iterator(); 1899 while (it.hasNext()) { 1900 Snippet sn = it.next(); 1901 writer.write(sn.source()); 1902 writer.write("\n"); 1903 } You can use .collect method like following even if write throws IOE: String sources = (at.hasOption("-all") ? state.snippets() : state.snippets().filter(this::mainActive)) .map(Snippet::source) .collect(Collectors.joining("\n")); writer.write(sources); In src/jdk.jshell/share/classes/jdk/jshell/Unit.java: // Look through all methods for a method of the same name, with the // same computed qualified parameter types Status overwrittenStatus = null;- for (MethodSnippet sn : state.methods()) {+ for (MethodSnippet sn : state.methods().collect(toList())) { if (sn != null && sn != msi && sn.status().isActive() && sn.name().equals(msi.name())) { if (qpt.equals(sn.qualifiedParameterTypes())) { overwrittenStatus = sn.status(); SnippetEvent se = new SnippetEvent( sn, overwrittenStatus, OVERWRITTEN, I'd like to avoid the collect(toList())+for-each because it need 2 pass for each data and kill the advantage of the streamification. Can you write this using StreamAPI or iterator from the stream? Regards, shinyafox(Shinya Yoshida) 2016-08-09 15:15 GMT+09:00 Robert Field : > Please review this deferred API review request. > Basically changing List<*> return to Stream<*> return for seven methods: > Stream snippets() > Stream variables() > Stream methods() > Stream types() > Stream imports() > Stream diagnostics(Snippet snippet) > Stream unresolvedDependencies(DeclarationSnippet snippet) > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8143964 > > Webrev: > http://cr.openjdk.java.net/~rfield/8143964v0.webrev/ > > Spec: > http://cr.openjdk.java.net/~rfield/8143964v0.jshellAPI/jdk/ > jshell/JShell.html > > Specdiff: > http://cr.openjdk.java.net/~rfield/8143964v0.specdiff/jdk/js > hell/JShell.html > > Thanks, > Robert > > From bitterfoxc at gmail.com Wed Aug 10 10:02:30 2016 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Wed, 10 Aug 2016 19:02:30 +0900 Subject: RFR 8143964: JShell API: convert query responses to Stream instead of List/Collection In-Reply-To: <57AA82AF.1050704@oracle.com> References: <57A97503.9020906@oracle.com> <57AA7926.2040503@oracle.com> <57AA82AF.1050704@oracle.com> Message-ID: Hi Robert, Thank you for your update. I've confirmed. LGTM! Regards, shinyafox(Shinya Yoshida) 2016-08-10 10:26 GMT+09:00 Robert Field : > Based on this review, I have used the first suggestion and changed the > second to use streaming to filter, leaving a list which is almost always > empty (this covers a rare case). The loop is then cleaner. > > // Check if there is a method whose user-declared parameter types are > // different (and thus has a different snippet) but whose compiled > parameter > // types are the same. if so, consider it an overwrite replacement. > private Status overwriteMatchingMethod(MethodSnippet msi) { > String qpt = msi.qualifiedParameterTypes(); > List matching = state.methods() > .filter(sn -> > sn != null > && sn != msi > && sn.status().isActive() > && sn.name().equals(msi.name()) > && qpt.equals(sn.qualifiedParameterTypes())) > .collect(toList()); > > // Look through all methods for a method of the same name, with the > // same computed qualified parameter types > Status overwrittenStatus = null; > for (MethodSnippet sn : matching) { > overwrittenStatus = sn.status(); > SnippetEvent se = new SnippetEvent( > sn, overwrittenStatus, OVERWRITTEN, > false, msi, null, null); > sn.setOverwritten(); > secondaryEvents.add(se); > state.debug(DBG_EVNT, > "Overwrite event #%d -- key: %s before: %s status: %s > sig: %b cause: %s\n", > secondaryEvents.size(), se.snippet(), > se.previousStatus(), > se.status(), se.isSignatureChange(), > se.causeSnippet()); > } > return overwrittenStatus; > } > > The only changes are these two loop changes (the spec is unchanged). New > webrev: > > http://cr.openjdk.java.net/~rfield/8143964v1.webrev/ > > Thanks, > Robert > > > > On 08/09/16 17:45, Robert Field wrote: > > > On 08/09/16 16:37, ShinyaYoshida wrote: > > Hi, Robert, > > I have 2 comments: > > 1895 Stream sns = at.hasOption("-all") > 1896 ? state.snippets() > 1897 : state.snippets().filter(this::mainActive); > 1898 Iterator it = sns.iterator(); > 1899 while (it.hasNext()) { > 1900 Snippet sn = it.next(); > 1901 writer.write(sn.source()); > 1902 writer.write("\n"); > 1903 } > > You can use .collect method like following even if write throws IOE: > > String sources = (at.hasOption("-all") > ? state.snippets() > : state.snippets().filter(this::mainActive)) > .map(Snippet::source) > .collect(Collectors.joining("\n")); > writer.write(sources); > > > I like that! > > > In src/jdk.jshell/share/classes/jdk/jshell/Unit.java: > // Look through all methods for a method of the same name, with the > // same computed qualified parameter types > Status overwrittenStatus = null;- for (MethodSnippet sn : state.methods()) {+ for (MethodSnippet sn : state.methods().collect(toList())) { > if (sn != null && sn != msi && sn.status().isActive() && sn.name().equals(msi.name())) { > if (qpt.equals(sn.qualifiedParameterTypes())) { > overwrittenStatus = sn.status(); > SnippetEvent se = new SnippetEvent( > sn, overwrittenStatus, OVERWRITTEN, > > I'd like to avoid the collect(toList())+for-each because it need 2 pass for each data and kill the advantage of the streamification. > > Can you write this using StreamAPI or iterator from the stream? > > > Unfortunately, this loop side-effects, it sets overwrittenStatus which is > returned by the method. Short of redesigning the set of methods that use > this, which I don't want to do at this stage, directly using Stream won't > work. > > I could switch to Iterator. Since for-loops only take Iterable (not > Iterator) it is clunky. Though I did do it elsewhere (e.g. above). > > Note: this bug-fix removes a ".collect(toList()" which was always done > behind the scenes. > > Thanks, > Robert > > Regards, > > shinyafox(Shinya Yoshida) > > > 2016-08-09 15:15 GMT+09:00 Robert Field : > >> Please review this deferred API review request. >> Basically changing List<*> return to Stream<*> return for seven methods: >> Stream snippets() >> Stream variables() >> Stream methods() >> Stream types() >> Stream imports() >> Stream diagnostics(Snippet snippet) >> Stream unresolvedDependencies(DeclarationSnippet snippet) >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8143964 >> >> Webrev: >> http://cr.openjdk.java.net/~rfield/8143964v0.webrev/ >> >> Spec: >> http://cr.openjdk.java.net/~rfield/8143964v0.jshellAPI/jdk/j >> shell/JShell.html >> >> Specdiff: >> http://cr.openjdk.java.net/~rfield/8143964v0.specdiff/jdk/js >> hell/JShell.html >> >> Thanks, >> Robert >> >> > > > From jan.lahoda at oracle.com Wed Aug 10 17:34:53 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 10 Aug 2016 19:34:53 +0200 Subject: RFR(xs) 8163500: JShell: ProblemList.txt update: 8139872 and 8080843 fixed In-Reply-To: <57AA0E7F.1060600@oracle.com> References: <57AA0E7F.1060600@oracle.com> Message-ID: <57AB65BD.304@oracle.com> Seems OK. Jan On 9.8.2016 19:10, Robert Field wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8163500 > > Diff: > --- a/test/ProblemList.txt Mon Aug 08 11:48:02 2016 -0700 > +++ b/test/ProblemList.txt Tue Aug 09 10:04:46 2016 -0700 > @@ -54,8 +54,6 @@ > # > # jshell > > -jdk/jshell/EditorPadTest.java 8139872 generic-all test requires a > non-headless environment > -jdk/jshell/ExternalEditorTest.java 8080843 generic-all invalid > key error occurs when external editor is used. > jdk/jshell/ToolBasicTest.java 8139873 generic-all JShell tests > failing > > ########################################################################### > > > Referenced bugs: > https://bugs.openjdk.java.net/browse/JDK-8139872 > https://bugs.openjdk.java.net/browse/JDK-8080843 > > Thanks, > Robert > From robert.field at oracle.com Wed Aug 10 22:39:46 2016 From: robert.field at oracle.com (Robert Field) Date: Wed, 10 Aug 2016 15:39:46 -0700 Subject: RFR(s) ASAP 8163817: JShell tests: disable minor failing editor tool cases: 8161276, 8163816, 8159229 Message-ID: <57ABAD32.1090900@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8163817 Webrev: http://cr.openjdk.java.net/~rfield/8163817v0.webrev/ Thanks, Robert From joe.darcy at oracle.com Wed Aug 10 22:41:42 2016 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 10 Aug 2016 15:41:42 -0700 Subject: RFR(s) ASAP 8163817: JShell tests: disable minor failing editor tool cases: 8161276, 8163816, 8159229 In-Reply-To: <57ABAD32.1090900@oracle.com> References: <57ABAD32.1090900@oracle.com> Message-ID: <4ac78fd1-da08-f878-1896-0801224f128c@oracle.com> +1 -Joe On 8/10/2016 3:39 PM, Robert Field wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8163817 > > Webrev: > http://cr.openjdk.java.net/~rfield/8163817v0.webrev/ > > Thanks, > Robert > From jan.lahoda at oracle.com Wed Aug 10 22:42:15 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 11 Aug 2016 00:42:15 +0200 Subject: RFR(s) ASAP 8163817: JShell tests: disable minor failing editor tool cases: 8161276, 8163816, 8159229 In-Reply-To: <57ABAD32.1090900@oracle.com> References: <57ABAD32.1090900@oracle.com> Message-ID: <57ABADC7.1070905@oracle.com> Ok. Jan On 11.8.2016 00:39, Robert Field wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8163817 > > Webrev: > http://cr.openjdk.java.net/~rfield/8163817v0.webrev/ > > Thanks, > Robert > From robert.field at oracle.com Thu Aug 11 06:01:15 2016 From: robert.field at oracle.com (Robert Field) Date: Wed, 10 Aug 2016 23:01:15 -0700 Subject: RFR 8159027: JShell API: SourceCodeAnalysis.Suggestion has constructor, ... Message-ID: <57AC14AB.5020501@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8159027 Webrev: http://cr.openjdk.java.net/~rfield/8159027v0.webrev/ API: http://cr.openjdk.java.net/~rfield/8159027v0.jshellAPI/ Specifically: http://cr.openjdk.java.net/~rfield/8159027v0.jshellAPI/jdk/jshell/SourceCodeAnalysis.Suggestion.html http://cr.openjdk.java.net/~rfield/8159027v0.jshellAPI/jdk/jshell/SourceCodeAnalysis.CompletionInfo.html Specdiff: http://cr.openjdk.java.net/~rfield/8159027v0.specdiff/overview-summary.html Specifically: http://cr.openjdk.java.net/~rfield/8159027v0.specdiff/jdk/jshell/SourceCodeAnalysis.Suggestion.html http://cr.openjdk.java.net/~rfield/8159027v0.specdiff/jdk/jshell/SourceCodeAnalysis.CompletionInfo.html Thanks, Robert From jan.lahoda at oracle.com Thu Aug 11 11:20:15 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 11 Aug 2016 13:20:15 +0200 Subject: RFR JDK-8129421&JDK-8129422: JShell tool completion bugs Message-ID: <57AC5F6F.8070506@oracle.com> Hello, Please review fix for completion bugs in the JShell tool. Bugs: https://bugs.openjdk.java.net/browse/JDK-8129421 https://bugs.openjdk.java.net/browse/JDK-8129422 Webrev: http://cr.openjdk.java.net/~jlahoda/8129422/webrev.00/ Thanks, Jan From robert.field at oracle.com Thu Aug 11 18:18:11 2016 From: robert.field at oracle.com (Robert Field) Date: Thu, 11 Aug 2016 11:18:11 -0700 Subject: RFR JDK-8129421&JDK-8129422: JShell tool completion bugs In-Reply-To: <57AC5F6F.8070506@oracle.com> References: <57AC5F6F.8070506@oracle.com> Message-ID: <57ACC163.1010001@oracle.com> Nice to have those. OK. -Robert On 08/11/16 04:20, Jan Lahoda wrote: > Hello, > > Please review fix for completion bugs in the JShell tool. > > Bugs: > https://bugs.openjdk.java.net/browse/JDK-8129421 > https://bugs.openjdk.java.net/browse/JDK-8129422 > > Webrev: > http://cr.openjdk.java.net/~jlahoda/8129422/webrev.00/ > > Thanks, > Jan From jan.lahoda at oracle.com Thu Aug 11 20:53:03 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 11 Aug 2016 22:53:03 +0200 Subject: RFR 8159027: JShell API: SourceCodeAnalysis.Suggestion has constructor, ... In-Reply-To: <57AC14AB.5020501@oracle.com> References: <57AC14AB.5020501@oracle.com> Message-ID: <57ACE5AF.1050507@oracle.com> Seems OK. Jan On 11.8.2016 08:01, Robert Field wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8159027 > > Webrev: > http://cr.openjdk.java.net/~rfield/8159027v0.webrev/ > > API: > http://cr.openjdk.java.net/~rfield/8159027v0.jshellAPI/ > > Specifically: > http://cr.openjdk.java.net/~rfield/8159027v0.jshellAPI/jdk/jshell/SourceCodeAnalysis.Suggestion.html > > http://cr.openjdk.java.net/~rfield/8159027v0.jshellAPI/jdk/jshell/SourceCodeAnalysis.CompletionInfo.html > > > Specdiff: > http://cr.openjdk.java.net/~rfield/8159027v0.specdiff/overview-summary.html > > Specifically: > http://cr.openjdk.java.net/~rfield/8159027v0.specdiff/jdk/jshell/SourceCodeAnalysis.Suggestion.html > > http://cr.openjdk.java.net/~rfield/8159027v0.specdiff/jdk/jshell/SourceCodeAnalysis.CompletionInfo.html > > > Thanks, > Robert > From robert.field at oracle.com Tue Aug 16 05:35:52 2016 From: robert.field at oracle.com (Robert Field) Date: Mon, 15 Aug 2016 22:35:52 -0700 Subject: jshell tool: opinions sought -- double-dash long-form command-line options Message-ID: <57B2A638.3000909@oracle.com> We would like the jshell tool to roll-out using the more modern double-dash options. Note though that it will ship in the jdk/bin directory where almost all commands use legacy option formats. Below I propose options for jshell, as this is not a black-and-white decision, I'd very much like input.... Current jshell options are -- -classpath Specify where to find user class files -cp Specify where to find user class files -startup One run replacement for the start-up definitions -nostartup Do not run the start-up definitions -feedback Specify the initial feedback mode. The mode may be predefined (silent, concise, normal, or verbose) or previously user-defined -q Quiet feedback. Same as: -feedback concise -qq Really quiet feedback. Same as: -feedback silent -v Verbose feedback. Same as: -feedback verbose -J Pass directly to the runtime system. Use one -J for each runtime flag or flag argument -R Pass to the remote runtime system. Use one -R for each remote flag or flag argument -help Print this synopsis of standard options -version Version information -fullversion Full Version information java options are mostly single-dash options, the current double-dash options are -- -cp -classpath --class-path A : separated list of directories, JAR archives, and ZIP archives to search for class files. -p --module-path ... A : separated list of directories, each directory is a directory of modules. --upgrade-module-path ... A : separated list of directories, each directory is a directory of modules that replace upgradeable modules in the runtime image -m [/] --module [/] the initial module to resolve, and the name of the main class to execute if not specified by the module --add-modules [,...] root modules to resolve in addition to the initial module. can also be ALL-DEFAULT, ALL-SYSTEM, ALL-MODULE-PATH. --limit-modules [,...] limit the universe of observable modules --list-modules [[,...]] list the observable modules and exit --dry-run create VM but do not execute main method. This --dry-run option may be useful for validating the command-line options such as the module system configuration. Of these, --class-path, --module-path, --add-modules, and maybe --upgrade-module-path seem appropriate for jshell. Proposed for jshell -- -classpath Specify where to find user class files -cp --class-path -p directory of modules. --module-path ... --upgrade-module-path ... directory of modules that replace upgradeable modules --add-modules [,...] root modules to resolve --startup One run replacement for the start-up definitions --nostartup Do not run the start-up definitions -n --feedback Specify the initial feedback mode. The mode may be predefined (silent, concise, normal, or verbose) or previously user-defined -q Quiet feedback. Same as: --feedback concise -qq Really quiet feedback. Same as: --feedback silent -v Verbose feedback. Same as: --feedback verbose -J Pass directly to the runtime system. -R Pass to the remote runtime system. --help Print this synopsis of standard options -help -h -version Version information --version -fullversion Full Version information --fullversion Thanks, Robert From jonathan.gibbons at oracle.com Tue Aug 16 15:07:45 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 16 Aug 2016 08:07:45 -0700 Subject: jshell tool: opinions sought -- double-dash long-form command-line options In-Reply-To: <57B2A638.3000909@oracle.com> References: <57B2A638.3000909@oracle.com> Message-ID: <57B32C41.6090208@oracle.com> Robert, Strong input: options that are common across tools should be the same across tools, for example, the set of module options. You're already suggesting that, so that's good. Additional input: double-dash options are typically a short series of words separated by hyphens (instead of concatenated words), so that makes for --no-startup instead of --nostartup. Note that double-dash options should allow '=' as a separator instead of white-space, as in --class-path=my:class:path This is not typically spelled out in detail in command line help, but there is typically a footnote to that effect at the end of the help. -- Jon On 08/15/2016 10:35 PM, Robert Field wrote: > We would like the jshell tool to roll-out using the more modern > double-dash options. Note though that it will ship in the jdk/bin > directory where almost all commands use legacy option formats. > > Below I propose options for jshell, as this is not a black-and-white > decision, I'd very much like input.... > > Current jshell options are -- > > -classpath Specify where to find user class files > -cp Specify where to find user class files > -startup One run replacement for the start-up definitions > -nostartup Do not run the start-up definitions > -feedback Specify the initial feedback mode. The mode > may be > predefined (silent, concise, normal, or > verbose) or > previously user-defined > -q Quiet feedback. Same as: -feedback concise > -qq Really quiet feedback. Same as: -feedback > silent > -v Verbose feedback. Same as: -feedback verbose > -J Pass directly to the runtime system. > Use one -J for each runtime flag or flag > argument > -R Pass to the remote runtime system. > Use one -R for each remote flag or flag argument > -help Print this synopsis of standard options > -version Version information > -fullversion Full Version information > > java options are mostly single-dash options, the current double-dash > options are -- > > -cp > -classpath > --class-path > A : separated list of directories, JAR archives, > and ZIP archives to search for class files. > -p > --module-path ... > A : separated list of directories, each directory > is a directory of modules. > --upgrade-module-path ... > A : separated list of directories, each directory > is a directory of modules that replace upgradeable > modules in the runtime image > -m [/] > --module [/] > the initial module to resolve, and the name of the > main class > to execute if not specified by the module > --add-modules [,...] > root modules to resolve in addition to the initial > module. > can also be ALL-DEFAULT, ALL-SYSTEM, > ALL-MODULE-PATH. > --limit-modules [,...] > limit the universe of observable modules > --list-modules [[,...]] > list the observable modules and exit > --dry-run create VM but do not execute main method. > This --dry-run option may be useful for validating the > command-line options such as the module system > configuration. > > Of these, --class-path, --module-path, --add-modules, and maybe > --upgrade-module-path seem appropriate for jshell. > > Proposed for jshell -- > > -classpath Specify where to find user class files > -cp > --class-path > > -p directory of modules. > --module-path ... > > --upgrade-module-path ... directory of modules that > replace upgradeable modules > > --add-modules [,...] root modules to resolve > > --startup One run replacement for the start-up > definitions > > --nostartup Do not run the start-up definitions Would be better as --no-startup > -n > > --feedback Specify the initial feedback mode. The mode > may be > predefined (silent, concise, normal, or > verbose) or > previously user-defined > > -q Quiet feedback. Same as: --feedback concise > > -qq Really quiet feedback. Same as: --feedback > silent > > -v Verbose feedback. Same as: --feedback verbose > > -J Pass directly to the runtime system. > > -R Pass to the remote runtime system. > > --help Print this synopsis of standard options > -help > -h > > -version Version information > --version > > -fullversion Full Version information > --fullversion ?? --full-version ?? > > > Thanks, > Robert > From robert.field at oracle.com Tue Aug 16 16:47:50 2016 From: robert.field at oracle.com (Robert Field) Date: Tue, 16 Aug 2016 09:47:50 -0700 Subject: jshell tool: opinions sought -- double-dash long-form command-line options In-Reply-To: <57B32C41.6090208@oracle.com> References: <57B2A638.3000909@oracle.com> <57B32C41.6090208@oracle.com> Message-ID: <0D268E17-86B2-4145-BEFD-B6783E231056@oracle.com> > On Aug 16, 2016, at 8:07 AM, Jonathan Gibbons wrote: > > Robert, > > Strong input: options that are common across tools should be the same across tools, for example, the set of module options. You're already suggesting that, so that's good. > > Additional input: double-dash options are typically a short series of words separated by hyphens (instead of concatenated words), so that makes for --no-startup instead of ?nostartup. Ah! Good point. > > Note that double-dash options should allow '=' as a separator instead of white-space, as in --class-path=my:class:path > This is not typically spelled out in detail in command line help, but there is typically a footnote to that effect at the end of the help. Right. I was pointed at JOpt-Simple since it does option parsing. I don?t think I?ll use it since error handling seems to lack the control I need. But, from that, I saw the =arg requirement. That should be easy to hand-craft. It also allows combining single-letter single-dash options, like -nq instead of -n -q. Given the multi-letter single-dash options, I?m not sure that makes sense to do. (continued) > > -- Jon > > On 08/15/2016 10:35 PM, Robert Field wrote: >> We would like the jshell tool to roll-out using the more modern double-dash options. Note though that it will ship in the jdk/bin directory where almost all commands use legacy option formats. >> >> Below I propose options for jshell, as this is not a black-and-white decision, I'd very much like input.... >> >> Current jshell options are -- >> >> -classpath Specify where to find user class files >> -cp Specify where to find user class files >> -startup One run replacement for the start-up definitions >> -nostartup Do not run the start-up definitions >> -feedback Specify the initial feedback mode. The mode may be >> predefined (silent, concise, normal, or verbose) or >> previously user-defined >> -q Quiet feedback. Same as: -feedback concise >> -qq Really quiet feedback. Same as: -feedback silent >> -v Verbose feedback. Same as: -feedback verbose >> -J Pass directly to the runtime system. >> Use one -J for each runtime flag or flag argument >> -R Pass to the remote runtime system. >> Use one -R for each remote flag or flag argument >> -help Print this synopsis of standard options >> -version Version information >> -fullversion Full Version information >> >> java options are mostly single-dash options, the current double-dash options are -- >> >> -cp >> -classpath >> --class-path >> A : separated list of directories, JAR archives, >> and ZIP archives to search for class files. >> -p >> --module-path ... >> A : separated list of directories, each directory >> is a directory of modules. >> --upgrade-module-path ... >> A : separated list of directories, each directory >> is a directory of modules that replace upgradeable >> modules in the runtime image >> -m [/] >> --module [/] >> the initial module to resolve, and the name of the main class >> to execute if not specified by the module >> --add-modules [,...] >> root modules to resolve in addition to the initial module. >> can also be ALL-DEFAULT, ALL-SYSTEM, >> ALL-MODULE-PATH. >> --limit-modules [,...] >> limit the universe of observable modules >> --list-modules [[,...]] >> list the observable modules and exit >> --dry-run create VM but do not execute main method. >> This --dry-run option may be useful for validating the >> command-line options such as the module system configuration. >> >> Of these, --class-path, --module-path, --add-modules, and maybe --upgrade-module-path seem appropriate for jshell. >> >> Proposed for jshell -- >> >> -classpath Specify where to find user class files >> -cp >> --class-path >> >> -p directory of modules. >> --module-path ... >> >> --upgrade-module-path ... directory of modules that replace upgradeable modules >> >> --add-modules [,...] root modules to resolve >> >> --startup One run replacement for the start-up definitions >> >> --nostartup Do not run the start-up definitions > > Would be better as --no-startup Y > >> -n >> >> --feedback Specify the initial feedback mode. The mode may be >> predefined (silent, concise, normal, or verbose) or >> previously user-defined >> >> -q Quiet feedback. Same as: --feedback concise >> >> -qq Really quiet feedback. Same as: --feedback silent >> >> -v Verbose feedback. Same as: --feedback verbose >> >> -J Pass directly to the runtime system. >> >> -R Pass to the remote runtime system. >> >> --help Print this synopsis of standard options >> -help >> -h >> >> -version Version information >> --version >> >> -fullversion Full Version information >> --fullversion > > ?? --full-version ?? Probably, y. Thanks much, Robert >> >> >> Thanks, >> Robert From jonathan.gibbons at oracle.com Tue Aug 16 17:03:10 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 16 Aug 2016 10:03:10 -0700 Subject: jshell tool: opinions sought -- double-dash long-form command-line options In-Reply-To: <0D268E17-86B2-4145-BEFD-B6783E231056@oracle.com> References: <57B2A638.3000909@oracle.com> <57B32C41.6090208@oracle.com> <0D268E17-86B2-4145-BEFD-B6783E231056@oracle.com> Message-ID: <57B3474E.6030102@oracle.com> Other new tools are using JOptSimple, so that is certainly a reasonable route, but that would (probably) imply dropping old-style options like -classpath and -cp. For a new tool, that would be very reasonable. I agree that mixing old-style options and combined single letter options is a bad idea. -- Jon On 08/16/2016 09:47 AM, Robert Field wrote: > >> On Aug 16, 2016, at 8:07 AM, Jonathan Gibbons >> > wrote: >> >> Robert, >> >> Strong input: options that are common across tools should be the >> same across tools, for example, the set of module options. You're >> already suggesting that, so that's good. >> >> Additional input: double-dash options are typically a short series of >> words separated by hyphens (instead of concatenated words), so that >> makes for --no-startup instead of ?nostartup. > > Ah! Good point. > >> >> Note that double-dash options should allow '=' as a separator instead >> of white-space, as in --class-path=my:class:path >> This is not typically spelled out in detail in command line help, but >> there is typically a footnote to that effect at the end of the help. > > Right. I was pointed at JOpt-Simple since it does option parsing. I > don?t think I?ll use it since error handling seems to lack the control > I need. But, from that, I saw the =arg requirement. That should be > easy to hand-craft. > > It also allows combining single-letter single-dash options, like -nq > instead of -n -q. Given the multi-letter single-dash options, I?m not > sure that makes sense to do. > > (continued) > >> >> -- Jon >> >> On 08/15/2016 10:35 PM, Robert Field wrote: >>> We would like the jshell tool to roll-out using the more modern >>> double-dash options. Note though that it will ship in the jdk/bin >>> directory where almost all commands use legacy option formats. >>> >>> Below I propose options for jshell, as this is not a black-and-white >>> decision, I'd very much like input.... >>> >>> Current jshell options are -- >>> >>> -classpath Specify where to find user class files >>> -cp Specify where to find user class files >>> -startup One run replacement for the start-up definitions >>> -nostartup Do not run the start-up definitions >>> -feedback Specify the initial feedback mode. The mode >>> may be >>> predefined (silent, concise, normal, or >>> verbose) or >>> previously user-defined >>> -q Quiet feedback. Same as: -feedback concise >>> -qq Really quiet feedback. Same as: -feedback >>> silent >>> -v Verbose feedback. Same as: -feedback verbose >>> -J Pass directly to the runtime system. >>> Use one -J for each runtime flag or flag >>> argument >>> -R Pass to the remote runtime system. >>> Use one -R for each remote flag or flag argument >>> -help Print this synopsis of standard options >>> -version Version information >>> -fullversion Full Version information >>> >>> java options are mostly single-dash options, the current double-dash >>> options are -- >>> >>> -cp >>> -classpath >>> --class-path >>> A : separated list of directories, JAR archives, >>> and ZIP archives to search for class files. >>> -p >>> --module-path ... >>> A : separated list of directories, each directory >>> is a directory of modules. >>> --upgrade-module-path ... >>> A : separated list of directories, each directory >>> is a directory of modules that replace upgradeable >>> modules in the runtime image >>> -m [/] >>> --module [/] >>> the initial module to resolve, and the name of the >>> main class >>> to execute if not specified by the module >>> --add-modules [,...] >>> root modules to resolve in addition to the initial >>> module. >>> can also be ALL-DEFAULT, ALL-SYSTEM, >>> ALL-MODULE-PATH. >>> --limit-modules [,...] >>> limit the universe of observable modules >>> --list-modules [[,...]] >>> list the observable modules and exit >>> --dry-run create VM but do not execute main method. >>> This --dry-run option may be useful for validating the >>> command-line options such as the module system >>> configuration. >>> >>> Of these, --class-path, --module-path, --add-modules, and maybe >>> --upgrade-module-path seem appropriate for jshell. >>> >>> Proposed for jshell -- >>> >>> -classpath Specify where to find user class files >>> -cp >>> --class-path >>> >>> -p directory of modules. >>> --module-path ... >>> >>> --upgrade-module-path ... directory of modules >>> that replace upgradeable modules >>> >>> --add-modules [,...] root modules to resolve >>> >>> --startup One run replacement for the start-up >>> definitions >>> >>> --nostartup Do not run the start-up definitions >> >> Would be better as --no-startup > > Y > >> >>> -n >>> >>> --feedback Specify the initial feedback mode. The mode >>> may be >>> predefined (silent, concise, normal, or >>> verbose) or >>> previously user-defined >>> >>> -q Quiet feedback. Same as: --feedback concise >>> >>> -qq Really quiet feedback. Same as: --feedback >>> silent >>> >>> -v Verbose feedback. Same as: --feedback verbose >>> >>> -J Pass directly to the runtime system. >>> >>> -R Pass to the remote runtime system. >>> >>> --help Print this synopsis of standard options >>> -help >>> -h >>> >>> -version Version information >>> --version >>> >>> -fullversion Full Version information >>> --fullversion >> >> ?? --full-version ?? > > Probably, y. > > Thanks much, > Robert > >>> >>> >>> Thanks, >>> Robert > From benjamin.john.evans at gmail.com Tue Aug 16 17:12:14 2016 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Tue, 16 Aug 2016 22:42:14 +0530 Subject: jshell tool: opinions sought -- double-dash long-form command-line options In-Reply-To: <57B3474E.6030102@oracle.com> References: <57B2A638.3000909@oracle.com> <57B32C41.6090208@oracle.com> <0D268E17-86B2-4145-BEFD-B6783E231056@oracle.com> <57B3474E.6030102@oracle.com> Message-ID: +1 to not mixing options. +1 to using JOptSimple It's also worth pointing out that one at least one major supported platform (Mac), the shortcuts are not all present by default, so while one can just say "javac" and it works, "jshell" (or "jjs") do not work out of the box. This is apparently due to legacy Apple packaging requirements that we can do nothing about, and is highly annoying. However, it does weaken the argument that arguments should be entirely consistent between tools, because the end user would have had to engage in a certain amout of platform hackery to make jshell work in the same way as the rest of the pre-Java 7 tools in $JAVA_HOME/bin I'd therefore argue that this is evidence in support of dropping the older-style of options and using the modern double-dash style as the default, along with whatever shortcuts / additional accommodations make sense. Just my 2c, Ben On Tue, Aug 16, 2016 at 10:33 PM, Jonathan Gibbons wrote: > Other new tools are using JOptSimple, so that is certainly a reasonable > route, but that would (probably) imply dropping old-style options like > -classpath and -cp. For a new tool, that would be very reasonable. > > I agree that mixing old-style options and combined single letter options is > a bad idea. > > -- Jon > > > On 08/16/2016 09:47 AM, Robert Field wrote: > >> >>> On Aug 16, 2016, at 8:07 AM, Jonathan Gibbons >>> > wrote: >>> >>> Robert, >>> >>> Strong input: options that are common across tools should be the same >>> across tools, for example, the set of module options. You're already >>> suggesting that, so that's good. >>> >>> Additional input: double-dash options are typically a short series of >>> words separated by hyphens (instead of concatenated words), so that makes >>> for --no-startup instead of ?nostartup. >> >> >> Ah! Good point. >> >>> >>> Note that double-dash options should allow '=' as a separator instead of >>> white-space, as in --class-path=my:class:path >>> This is not typically spelled out in detail in command line help, but >>> there is typically a footnote to that effect at the end of the help. >> >> >> Right. I was pointed at JOpt-Simple since it does option parsing. I >> don?t think I?ll use it since error handling seems to lack the control I >> need. But, from that, I saw the =arg requirement. That should be easy to >> hand-craft. >> >> It also allows combining single-letter single-dash options, like -nq >> instead of -n -q. Given the multi-letter single-dash options, I?m not sure >> that makes sense to do. >> >> (continued) >> >>> >>> -- Jon >>> >>> On 08/15/2016 10:35 PM, Robert Field wrote: >>>> >>>> We would like the jshell tool to roll-out using the more modern >>>> double-dash options. Note though that it will ship in the jdk/bin directory >>>> where almost all commands use legacy option formats. >>>> >>>> Below I propose options for jshell, as this is not a black-and-white >>>> decision, I'd very much like input.... >>>> >>>> Current jshell options are -- >>>> >>>> -classpath Specify where to find user class files >>>> -cp Specify where to find user class files >>>> -startup One run replacement for the start-up definitions >>>> -nostartup Do not run the start-up definitions >>>> -feedback Specify the initial feedback mode. The mode may >>>> be >>>> predefined (silent, concise, normal, or verbose) >>>> or >>>> previously user-defined >>>> -q Quiet feedback. Same as: -feedback concise >>>> -qq Really quiet feedback. Same as: -feedback >>>> silent >>>> -v Verbose feedback. Same as: -feedback verbose >>>> -J Pass directly to the runtime system. >>>> Use one -J for each runtime flag or flag >>>> argument >>>> -R Pass to the remote runtime system. >>>> Use one -R for each remote flag or flag argument >>>> -help Print this synopsis of standard options >>>> -version Version information >>>> -fullversion Full Version information >>>> >>>> java options are mostly single-dash options, the current double-dash >>>> options are -- >>>> >>>> -cp >>>> -classpath >>>> --class-path >>>> A : separated list of directories, JAR archives, >>>> and ZIP archives to search for class files. >>>> -p >>>> --module-path ... >>>> A : separated list of directories, each directory >>>> is a directory of modules. >>>> --upgrade-module-path ... >>>> A : separated list of directories, each directory >>>> is a directory of modules that replace upgradeable >>>> modules in the runtime image >>>> -m [/] >>>> --module [/] >>>> the initial module to resolve, and the name of the main >>>> class >>>> to execute if not specified by the module >>>> --add-modules [,...] >>>> root modules to resolve in addition to the initial >>>> module. >>>> can also be ALL-DEFAULT, ALL-SYSTEM, >>>> ALL-MODULE-PATH. >>>> --limit-modules [,...] >>>> limit the universe of observable modules >>>> --list-modules [[,...]] >>>> list the observable modules and exit >>>> --dry-run create VM but do not execute main method. >>>> This --dry-run option may be useful for validating the >>>> command-line options such as the module system >>>> configuration. >>>> >>>> Of these, --class-path, --module-path, --add-modules, and maybe >>>> --upgrade-module-path seem appropriate for jshell. >>>> >>>> Proposed for jshell -- >>>> >>>> -classpath Specify where to find user class files >>>> -cp >>>> --class-path >>>> >>>> -p directory of modules. >>>> --module-path ... >>>> >>>> --upgrade-module-path ... directory of modules that >>>> replace upgradeable modules >>>> >>>> --add-modules [,...] root modules to resolve >>>> >>>> --startup One run replacement for the start-up >>>> definitions >>>> >>>> --nostartup Do not run the start-up definitions >>> >>> >>> Would be better as --no-startup >> >> >> Y >> >>> >>>> -n >>>> >>>> --feedback Specify the initial feedback mode. The mode may >>>> be >>>> predefined (silent, concise, normal, or verbose) >>>> or >>>> previously user-defined >>>> >>>> -q Quiet feedback. Same as: --feedback concise >>>> >>>> -qq Really quiet feedback. Same as: --feedback >>>> silent >>>> >>>> -v Verbose feedback. Same as: --feedback verbose >>>> >>>> -J Pass directly to the runtime system. >>>> >>>> -R Pass to the remote runtime system. >>>> >>>> --help Print this synopsis of standard options >>>> -help >>>> -h >>>> >>>> -version Version information >>>> --version >>>> >>>> -fullversion Full Version information >>>> --fullversion >>> >>> >>> ?? --full-version ?? >> >> >> Probably, y. >> >> Thanks much, >> Robert >> >>>> >>>> >>>> Thanks, >>>> Robert >> >> > From jonathan.gibbons at oracle.com Tue Aug 16 17:19:05 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 16 Aug 2016 10:19:05 -0700 Subject: jshell tool: opinions sought -- double-dash long-form command-line options In-Reply-To: References: <57B2A638.3000909@oracle.com> <57B32C41.6090208@oracle.com> <0D268E17-86B2-4145-BEFD-B6783E231056@oracle.com> <57B3474E.6030102@oracle.com> Message-ID: <57B34B09.2020502@oracle.com> Ben, The argument about consistency between tools was intended to be specific to the syntax and semantics of specific options, like --class-path, --module-path, --add-modules, etc. I didn't mean it to extend to "all ways of specifying a classpath", as in "--class-path", "-classpath", and "-cp". jmods, for example, is a new tool, that only supports --class-path (not -classpath, -cp) -- Jon On 08/16/2016 10:12 AM, Ben Evans wrote: > +1 to not mixing options. > > +1 to using JOptSimple > > It's also worth pointing out that one at least one major supported > platform (Mac), the shortcuts are not all present by default, so while > one can just say "javac" and it works, "jshell" (or "jjs") do not work > out of the box. This is apparently due to legacy Apple packaging > requirements that we can do nothing about, and is highly annoying. > > However, it does weaken the argument that arguments should be entirely > consistent between tools, because the end user would have had to > engage in a certain amout of platform hackery to make jshell work in > the same way as the rest of the pre-Java 7 tools in $JAVA_HOME/bin > > I'd therefore argue that this is evidence in support of dropping the > older-style of options and using the modern double-dash style as the > default, along with whatever shortcuts / additional accommodations > make sense. > > Just my 2c, > > Ben > > On Tue, Aug 16, 2016 at 10:33 PM, Jonathan Gibbons > wrote: >> Other new tools are using JOptSimple, so that is certainly a reasonable >> route, but that would (probably) imply dropping old-style options like >> -classpath and -cp. For a new tool, that would be very reasonable. >> >> I agree that mixing old-style options and combined single letter options is >> a bad idea. >> >> -- Jon >> >> >> On 08/16/2016 09:47 AM, Robert Field wrote: >> >>>> On Aug 16, 2016, at 8:07 AM, Jonathan Gibbons >>>> > wrote: >>>> >>>> Robert, >>>> >>>> Strong input: options that are common across tools should be the same >>>> across tools, for example, the set of module options. You're already >>>> suggesting that, so that's good. >>>> >>>> Additional input: double-dash options are typically a short series of >>>> words separated by hyphens (instead of concatenated words), so that makes >>>> for --no-startup instead of ?nostartup. >>> >>> Ah! Good point. >>> >>>> Note that double-dash options should allow '=' as a separator instead of >>>> white-space, as in --class-path=my:class:path >>>> This is not typically spelled out in detail in command line help, but >>>> there is typically a footnote to that effect at the end of the help. >>> >>> Right. I was pointed at JOpt-Simple since it does option parsing. I >>> don?t think I?ll use it since error handling seems to lack the control I >>> need. But, from that, I saw the =arg requirement. That should be easy to >>> hand-craft. >>> >>> It also allows combining single-letter single-dash options, like -nq >>> instead of -n -q. Given the multi-letter single-dash options, I?m not sure >>> that makes sense to do. >>> >>> (continued) >>> >>>> -- Jon >>>> >>>> On 08/15/2016 10:35 PM, Robert Field wrote: >>>>> We would like the jshell tool to roll-out using the more modern >>>>> double-dash options. Note though that it will ship in the jdk/bin directory >>>>> where almost all commands use legacy option formats. >>>>> >>>>> Below I propose options for jshell, as this is not a black-and-white >>>>> decision, I'd very much like input.... >>>>> >>>>> Current jshell options are -- >>>>> >>>>> -classpath Specify where to find user class files >>>>> -cp Specify where to find user class files >>>>> -startup One run replacement for the start-up definitions >>>>> -nostartup Do not run the start-up definitions >>>>> -feedback Specify the initial feedback mode. The mode may >>>>> be >>>>> predefined (silent, concise, normal, or verbose) >>>>> or >>>>> previously user-defined >>>>> -q Quiet feedback. Same as: -feedback concise >>>>> -qq Really quiet feedback. Same as: -feedback >>>>> silent >>>>> -v Verbose feedback. Same as: -feedback verbose >>>>> -J Pass directly to the runtime system. >>>>> Use one -J for each runtime flag or flag >>>>> argument >>>>> -R Pass to the remote runtime system. >>>>> Use one -R for each remote flag or flag argument >>>>> -help Print this synopsis of standard options >>>>> -version Version information >>>>> -fullversion Full Version information >>>>> >>>>> java options are mostly single-dash options, the current double-dash >>>>> options are -- >>>>> >>>>> -cp >>>>> -classpath >>>>> --class-path >>>>> A : separated list of directories, JAR archives, >>>>> and ZIP archives to search for class files. >>>>> -p >>>>> --module-path ... >>>>> A : separated list of directories, each directory >>>>> is a directory of modules. >>>>> --upgrade-module-path ... >>>>> A : separated list of directories, each directory >>>>> is a directory of modules that replace upgradeable >>>>> modules in the runtime image >>>>> -m [/] >>>>> --module [/] >>>>> the initial module to resolve, and the name of the main >>>>> class >>>>> to execute if not specified by the module >>>>> --add-modules [,...] >>>>> root modules to resolve in addition to the initial >>>>> module. >>>>> can also be ALL-DEFAULT, ALL-SYSTEM, >>>>> ALL-MODULE-PATH. >>>>> --limit-modules [,...] >>>>> limit the universe of observable modules >>>>> --list-modules [[,...]] >>>>> list the observable modules and exit >>>>> --dry-run create VM but do not execute main method. >>>>> This --dry-run option may be useful for validating the >>>>> command-line options such as the module system >>>>> configuration. >>>>> >>>>> Of these, --class-path, --module-path, --add-modules, and maybe >>>>> --upgrade-module-path seem appropriate for jshell. >>>>> >>>>> Proposed for jshell -- >>>>> >>>>> -classpath Specify where to find user class files >>>>> -cp >>>>> --class-path >>>>> >>>>> -p directory of modules. >>>>> --module-path ... >>>>> >>>>> --upgrade-module-path ... directory of modules that >>>>> replace upgradeable modules >>>>> >>>>> --add-modules [,...] root modules to resolve >>>>> >>>>> --startup One run replacement for the start-up >>>>> definitions >>>>> >>>>> --nostartup Do not run the start-up definitions >>>> >>>> Would be better as --no-startup >>> >>> Y >>> >>>>> -n >>>>> >>>>> --feedback Specify the initial feedback mode. The mode may >>>>> be >>>>> predefined (silent, concise, normal, or verbose) >>>>> or >>>>> previously user-defined >>>>> >>>>> -q Quiet feedback. Same as: --feedback concise >>>>> >>>>> -qq Really quiet feedback. Same as: --feedback >>>>> silent >>>>> >>>>> -v Verbose feedback. Same as: --feedback verbose >>>>> >>>>> -J Pass directly to the runtime system. >>>>> >>>>> -R Pass to the remote runtime system. >>>>> >>>>> --help Print this synopsis of standard options >>>>> -help >>>>> -h >>>>> >>>>> -version Version information >>>>> --version >>>>> >>>>> -fullversion Full Version information >>>>> --fullversion >>>> >>>> ?? --full-version ?? >>> >>> Probably, y. >>> >>> Thanks much, >>> Robert >>> >>>>> >>>>> Thanks, >>>>> Robert >>> From john.r.rose at oracle.com Tue Aug 16 18:13:54 2016 From: john.r.rose at oracle.com (John Rose) Date: Tue, 16 Aug 2016 11:13:54 -0700 Subject: jshell tool: opinions sought -- double-dash long-form command-line options In-Reply-To: <57B2A638.3000909@oracle.com> References: <57B2A638.3000909@oracle.com> Message-ID: <5DEA3B13-D55D-456F-A5C0-E6CFE4ED5BDC@oracle.com> FWIW I used a compact table driven approach to CLI options in the pack200 tool. It might help here. Not a library, just a self-documenting code pattern. http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c7550333c4ba/src/java.base/share/classes/com/sun/java/util/jar/pack/Driver.java#l434 I agree with the trend to more modern option syntax. ? John From robert.field at oracle.com Wed Aug 17 05:44:44 2016 From: robert.field at oracle.com (Robert Field) Date: Tue, 16 Aug 2016 22:44:44 -0700 Subject: jshell tool: opinions sought -- double-dash long-form command-line options In-Reply-To: <57B34B09.2020502@oracle.com> References: <57B2A638.3000909@oracle.com> <57B32C41.6090208@oracle.com> <0D268E17-86B2-4145-BEFD-B6783E231056@oracle.com> <57B3474E.6030102@oracle.com> <57B34B09.2020502@oracle.com> Message-ID: <57B3F9CC.9090002@oracle.com> If jmods does not support legacy single-dash multiple-letter options, then should jshell? Should we trim it down to -- --class-path Specify where to find user class files --module-path ... directory of modules. -p --upgrade-module-path ... directory of modules that replace upgradeable modules --add-modules [,...] root modules to resolve --startup One run replacement for the start-up definitions --no-startup Do not run the start-up definitions -n --feedback Specify the initial feedback mode. The mode may be predefined (silent, concise, normal, or verbose) or previously user-defined -q Quiet feedback. Same as: --feedback concise -s Really quiet feedback. Same as: --feedback silent -v Verbose feedback. Same as: --feedback verbose -J Pass directly to the runtime system. -R Pass to the remote runtime system. --help Print this synopsis of standard options -h --version Version information --full-version Full Version information Eliminating -- -classpath Specify where to find user class files -cp -help Print this synopsis of standard options -version Version information -fullversion Full Version information Note: -qq is switched to -s. And, per Jon's suggestion, changed the spelling of --no-startup and --full-version to include separating dashes. With this, single-letter options could be combined: e.g. -nq -Robert On 08/16/16 10:19, Jonathan Gibbons wrote: > Ben, > > The argument about consistency between tools was intended to be > specific to the syntax and semantics of specific options, like > --class-path, --module-path, --add-modules, etc. > > I didn't mean it to extend to "all ways of specifying a classpath", as > in "--class-path", "-classpath", and "-cp". > > jmods, for example, is a new tool, that only supports --class-path > (not -classpath, -cp) > > -- Jon > > On 08/16/2016 10:12 AM, Ben Evans wrote: >> +1 to not mixing options. >> >> +1 to using JOptSimple >> >> It's also worth pointing out that one at least one major supported >> platform (Mac), the shortcuts are not all present by default, so while >> one can just say "javac" and it works, "jshell" (or "jjs") do not work >> out of the box. This is apparently due to legacy Apple packaging >> requirements that we can do nothing about, and is highly annoying. >> >> However, it does weaken the argument that arguments should be entirely >> consistent between tools, because the end user would have had to >> engage in a certain amout of platform hackery to make jshell work in >> the same way as the rest of the pre-Java 7 tools in $JAVA_HOME/bin >> >> I'd therefore argue that this is evidence in support of dropping the >> older-style of options and using the modern double-dash style as the >> default, along with whatever shortcuts / additional accommodations >> make sense. >> >> Just my 2c, >> >> Ben >> >> On Tue, Aug 16, 2016 at 10:33 PM, Jonathan Gibbons >> wrote: >>> Other new tools are using JOptSimple, so that is certainly a reasonable >>> route, but that would (probably) imply dropping old-style options like >>> -classpath and -cp. For a new tool, that would be very reasonable. >>> >>> I agree that mixing old-style options and combined single letter >>> options is >>> a bad idea. >>> >>> -- Jon >>> >>> >>> On 08/16/2016 09:47 AM, Robert Field wrote: >>> >>>>> On Aug 16, 2016, at 8:07 AM, Jonathan Gibbons >>>>> > >>>>> wrote: >>>>> >>>>> Robert, >>>>> >>>>> Strong input: options that are common across tools should be the >>>>> same >>>>> across tools, for example, the set of module options. You're already >>>>> suggesting that, so that's good. >>>>> >>>>> Additional input: double-dash options are typically a short series of >>>>> words separated by hyphens (instead of concatenated words), so >>>>> that makes >>>>> for --no-startup instead of ?nostartup. >>>> >>>> Ah! Good point. >>>> >>>>> Note that double-dash options should allow '=' as a separator >>>>> instead of >>>>> white-space, as in --class-path=my:class:path >>>>> This is not typically spelled out in detail in command line help, but >>>>> there is typically a footnote to that effect at the end of the help. >>>> >>>> Right. I was pointed at JOpt-Simple since it does option parsing. I >>>> don?t think I?ll use it since error handling seems to lack the >>>> control I >>>> need. But, from that, I saw the =arg requirement. That should be >>>> easy to >>>> hand-craft. >>>> >>>> It also allows combining single-letter single-dash options, like -nq >>>> instead of -n -q. Given the multi-letter single-dash options, I?m >>>> not sure >>>> that makes sense to do. >>>> >>>> (continued) >>>> >>>>> -- Jon >>>>> >>>>> On 08/15/2016 10:35 PM, Robert Field wrote: >>>>>> We would like the jshell tool to roll-out using the more modern >>>>>> double-dash options. Note though that it will ship in the >>>>>> jdk/bin directory >>>>>> where almost all commands use legacy option formats. >>>>>> >>>>>> Below I propose options for jshell, as this is not a black-and-white >>>>>> decision, I'd very much like input.... >>>>>> >>>>>> Current jshell options are -- >>>>>> >>>>>> -classpath Specify where to find user class files >>>>>> -cp Specify where to find user class files >>>>>> -startup One run replacement for the start-up >>>>>> definitions >>>>>> -nostartup Do not run the start-up definitions >>>>>> -feedback Specify the initial feedback mode. The >>>>>> mode may >>>>>> be >>>>>> predefined (silent, concise, normal, or >>>>>> verbose) >>>>>> or >>>>>> previously user-defined >>>>>> -q Quiet feedback. Same as: -feedback concise >>>>>> -qq Really quiet feedback. Same as: -feedback >>>>>> silent >>>>>> -v Verbose feedback. Same as: -feedback >>>>>> verbose >>>>>> -J Pass directly to the runtime system. >>>>>> Use one -J for each runtime flag or flag >>>>>> argument >>>>>> -R Pass to the remote runtime system. >>>>>> Use one -R for each remote flag or flag >>>>>> argument >>>>>> -help Print this synopsis of standard options >>>>>> -version Version information >>>>>> -fullversion Full Version information >>>>>> >>>>>> java options are mostly single-dash options, the current double-dash >>>>>> options are -- >>>>>> >>>>>> -cp >>>>>> -classpath >>>>>> --class-path >>>>> files> >>>>>> A : separated list of directories, JAR archives, >>>>>> and ZIP archives to search for class files. >>>>>> -p >>>>>> --module-path ... >>>>>> A : separated list of directories, each directory >>>>>> is a directory of modules. >>>>>> --upgrade-module-path ... >>>>>> A : separated list of directories, each directory >>>>>> is a directory of modules that replace upgradeable >>>>>> modules in the runtime image >>>>>> -m [/] >>>>>> --module [/] >>>>>> the initial module to resolve, and the name of >>>>>> the main >>>>>> class >>>>>> to execute if not specified by the module >>>>>> --add-modules [,...] >>>>>> root modules to resolve in addition to the initial >>>>>> module. >>>>>> can also be ALL-DEFAULT, ALL-SYSTEM, >>>>>> ALL-MODULE-PATH. >>>>>> --limit-modules [,...] >>>>>> limit the universe of observable modules >>>>>> --list-modules [[,...]] >>>>>> list the observable modules and exit >>>>>> --dry-run create VM but do not execute main method. >>>>>> This --dry-run option may be useful for >>>>>> validating the >>>>>> command-line options such as the module system >>>>>> configuration. >>>>>> >>>>>> Of these, --class-path, --module-path, --add-modules, and maybe >>>>>> --upgrade-module-path seem appropriate for jshell. >>>>>> >>>>>> Proposed for jshell -- >>>>>> >>>>>> -classpath Specify where to find user class files >>>>>> -cp >>>>>> --class-path >>>>>> >>>>>> -p directory of modules. >>>>>> --module-path ... >>>>>> >>>>>> --upgrade-module-path ... directory of modules that >>>>>> replace upgradeable modules >>>>>> >>>>>> --add-modules [,...] root modules to >>>>>> resolve >>>>>> >>>>>> --startup One run replacement for the start-up >>>>>> definitions >>>>>> >>>>>> --nostartup Do not run the start-up definitions >>>>> >>>>> Would be better as --no-startup >>>> >>>> Y >>>> >>>>>> -n >>>>>> >>>>>> --feedback Specify the initial feedback mode. The >>>>>> mode may >>>>>> be >>>>>> predefined (silent, concise, normal, or >>>>>> verbose) >>>>>> or >>>>>> previously user-defined >>>>>> >>>>>> -q Quiet feedback. Same as: --feedback >>>>>> concise >>>>>> >>>>>> -qq Really quiet feedback. Same as: --feedback >>>>>> silent >>>>>> >>>>>> -v Verbose feedback. Same as: --feedback >>>>>> verbose >>>>>> >>>>>> -J Pass directly to the runtime system. >>>>>> >>>>>> -R Pass to the remote runtime system. >>>>>> >>>>>> --help Print this synopsis of standard options >>>>>> -help >>>>>> -h >>>>>> >>>>>> -version Version information >>>>>> --version >>>>>> >>>>>> -fullversion Full Version information >>>>>> --fullversion >>>>> >>>>> ?? --full-version ?? >>>> >>>> Probably, y. >>>> >>>> Thanks much, >>>> Robert >>>> >>>>>> >>>>>> Thanks, >>>>>> Robert >>>> > From benjamin.john.evans at gmail.com Wed Aug 17 06:16:34 2016 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Wed, 17 Aug 2016 11:46:34 +0530 Subject: jshell tool: opinions sought -- double-dash long-form command-line options In-Reply-To: <57B3F9CC.9090002@oracle.com> References: <57B2A638.3000909@oracle.com> <57B32C41.6090208@oracle.com> <0D268E17-86B2-4145-BEFD-B6783E231056@oracle.com> <57B3474E.6030102@oracle.com> <57B34B09.2020502@oracle.com> <57B3F9CC.9090002@oracle.com> Message-ID: That makes sense to me - I'd say go for it. Thanks, Ben On Wed, Aug 17, 2016 at 11:14 AM, Robert Field wrote: > If jmods does not support legacy single-dash multiple-letter options, then > should jshell? > > Should we trim it down to -- > > --class-path Specify where to find user class files > > --module-path ... directory of modules. > -p > > --upgrade-module-path ... directory of modules that > replace upgradeable modules > > --add-modules [,...] root modules to resolve > > --startup One run replacement for the start-up definitions > > --no-startup Do not run the start-up definitions > -n > > --feedback Specify the initial feedback mode. The mode may be > predefined (silent, concise, normal, or verbose) or > previously user-defined > > -q Quiet feedback. Same as: --feedback concise > > -s Really quiet feedback. Same as: --feedback silent > > -v Verbose feedback. Same as: --feedback verbose > > -J Pass directly to the runtime system. > > -R Pass to the remote runtime system. > > --help Print this synopsis of standard options > -h > > --version Version information > > --full-version Full Version information > > Eliminating -- > > -classpath Specify where to find user class files > -cp > > -help Print this synopsis of standard options > > -version Version information > > -fullversion Full Version information > > Note: -qq is switched to -s. And, per Jon's suggestion, changed the > spelling of --no-startup and --full-version to include separating dashes. > > With this, single-letter options could be combined: e.g. -nq > > -Robert > > > On 08/16/16 10:19, Jonathan Gibbons wrote: >> >> Ben, >> >> The argument about consistency between tools was intended to be specific >> to the syntax and semantics of specific options, like --class-path, >> --module-path, --add-modules, etc. >> >> I didn't mean it to extend to "all ways of specifying a classpath", as in >> "--class-path", "-classpath", and "-cp". >> >> jmods, for example, is a new tool, that only supports --class-path (not >> -classpath, -cp) >> >> -- Jon >> >> On 08/16/2016 10:12 AM, Ben Evans wrote: >>> >>> +1 to not mixing options. >>> >>> +1 to using JOptSimple >>> >>> It's also worth pointing out that one at least one major supported >>> platform (Mac), the shortcuts are not all present by default, so while >>> one can just say "javac" and it works, "jshell" (or "jjs") do not work >>> out of the box. This is apparently due to legacy Apple packaging >>> requirements that we can do nothing about, and is highly annoying. >>> >>> However, it does weaken the argument that arguments should be entirely >>> consistent between tools, because the end user would have had to >>> engage in a certain amout of platform hackery to make jshell work in >>> the same way as the rest of the pre-Java 7 tools in $JAVA_HOME/bin >>> >>> I'd therefore argue that this is evidence in support of dropping the >>> older-style of options and using the modern double-dash style as the >>> default, along with whatever shortcuts / additional accommodations >>> make sense. >>> >>> Just my 2c, >>> >>> Ben >>> >>> On Tue, Aug 16, 2016 at 10:33 PM, Jonathan Gibbons >>> wrote: >>>> >>>> Other new tools are using JOptSimple, so that is certainly a reasonable >>>> route, but that would (probably) imply dropping old-style options like >>>> -classpath and -cp. For a new tool, that would be very reasonable. >>>> >>>> I agree that mixing old-style options and combined single letter options >>>> is >>>> a bad idea. >>>> >>>> -- Jon >>>> >>>> >>>> On 08/16/2016 09:47 AM, Robert Field wrote: >>>> >>>>>> On Aug 16, 2016, at 8:07 AM, Jonathan Gibbons >>>>>> > >>>>>> wrote: >>>>>> >>>>>> Robert, >>>>>> >>>>>> Strong input: options that are common across tools should be the same >>>>>> across tools, for example, the set of module options. You're already >>>>>> suggesting that, so that's good. >>>>>> >>>>>> Additional input: double-dash options are typically a short series of >>>>>> words separated by hyphens (instead of concatenated words), so that >>>>>> makes >>>>>> for --no-startup instead of ?nostartup. >>>>> >>>>> >>>>> Ah! Good point. >>>>> >>>>>> Note that double-dash options should allow '=' as a separator instead >>>>>> of >>>>>> white-space, as in --class-path=my:class:path >>>>>> This is not typically spelled out in detail in command line help, but >>>>>> there is typically a footnote to that effect at the end of the help. >>>>> >>>>> >>>>> Right. I was pointed at JOpt-Simple since it does option parsing. I >>>>> don?t think I?ll use it since error handling seems to lack the control >>>>> I >>>>> need. But, from that, I saw the =arg requirement. That should be easy >>>>> to >>>>> hand-craft. >>>>> >>>>> It also allows combining single-letter single-dash options, like -nq >>>>> instead of -n -q. Given the multi-letter single-dash options, I?m not >>>>> sure >>>>> that makes sense to do. >>>>> >>>>> (continued) >>>>> >>>>>> -- Jon >>>>>> >>>>>> On 08/15/2016 10:35 PM, Robert Field wrote: >>>>>>> >>>>>>> We would like the jshell tool to roll-out using the more modern >>>>>>> double-dash options. Note though that it will ship in the jdk/bin >>>>>>> directory >>>>>>> where almost all commands use legacy option formats. >>>>>>> >>>>>>> Below I propose options for jshell, as this is not a black-and-white >>>>>>> decision, I'd very much like input.... >>>>>>> >>>>>>> Current jshell options are -- >>>>>>> >>>>>>> -classpath Specify where to find user class files >>>>>>> -cp Specify where to find user class files >>>>>>> -startup One run replacement for the start-up >>>>>>> definitions >>>>>>> -nostartup Do not run the start-up definitions >>>>>>> -feedback Specify the initial feedback mode. The mode >>>>>>> may >>>>>>> be >>>>>>> predefined (silent, concise, normal, or >>>>>>> verbose) >>>>>>> or >>>>>>> previously user-defined >>>>>>> -q Quiet feedback. Same as: -feedback concise >>>>>>> -qq Really quiet feedback. Same as: -feedback >>>>>>> silent >>>>>>> -v Verbose feedback. Same as: -feedback >>>>>>> verbose >>>>>>> -J Pass directly to the runtime system. >>>>>>> Use one -J for each runtime flag or flag >>>>>>> argument >>>>>>> -R Pass to the remote runtime system. >>>>>>> Use one -R for each remote flag or flag >>>>>>> argument >>>>>>> -help Print this synopsis of standard options >>>>>>> -version Version information >>>>>>> -fullversion Full Version information >>>>>>> >>>>>>> java options are mostly single-dash options, the current double-dash >>>>>>> options are -- >>>>>>> >>>>>>> -cp >>>>>>> -classpath >>>>>>> --class-path >>>>>>> A : separated list of directories, JAR archives, >>>>>>> and ZIP archives to search for class files. >>>>>>> -p >>>>>>> --module-path ... >>>>>>> A : separated list of directories, each directory >>>>>>> is a directory of modules. >>>>>>> --upgrade-module-path ... >>>>>>> A : separated list of directories, each directory >>>>>>> is a directory of modules that replace upgradeable >>>>>>> modules in the runtime image >>>>>>> -m [/] >>>>>>> --module [/] >>>>>>> the initial module to resolve, and the name of the >>>>>>> main >>>>>>> class >>>>>>> to execute if not specified by the module >>>>>>> --add-modules [,...] >>>>>>> root modules to resolve in addition to the initial >>>>>>> module. >>>>>>> can also be ALL-DEFAULT, ALL-SYSTEM, >>>>>>> ALL-MODULE-PATH. >>>>>>> --limit-modules [,...] >>>>>>> limit the universe of observable modules >>>>>>> --list-modules [[,...]] >>>>>>> list the observable modules and exit >>>>>>> --dry-run create VM but do not execute main method. >>>>>>> This --dry-run option may be useful for validating >>>>>>> the >>>>>>> command-line options such as the module system >>>>>>> configuration. >>>>>>> >>>>>>> Of these, --class-path, --module-path, --add-modules, and maybe >>>>>>> --upgrade-module-path seem appropriate for jshell. >>>>>>> >>>>>>> Proposed for jshell -- >>>>>>> >>>>>>> -classpath Specify where to find user class files >>>>>>> -cp >>>>>>> --class-path >>>>>>> >>>>>>> -p directory of modules. >>>>>>> --module-path ... >>>>>>> >>>>>>> --upgrade-module-path ... directory of modules that >>>>>>> replace upgradeable modules >>>>>>> >>>>>>> --add-modules [,...] root modules to >>>>>>> resolve >>>>>>> >>>>>>> --startup One run replacement for the start-up >>>>>>> definitions >>>>>>> >>>>>>> --nostartup Do not run the start-up definitions >>>>>> >>>>>> >>>>>> Would be better as --no-startup >>>>> >>>>> >>>>> Y >>>>> >>>>>>> -n >>>>>>> >>>>>>> --feedback Specify the initial feedback mode. The mode >>>>>>> may >>>>>>> be >>>>>>> predefined (silent, concise, normal, or >>>>>>> verbose) >>>>>>> or >>>>>>> previously user-defined >>>>>>> >>>>>>> -q Quiet feedback. Same as: --feedback concise >>>>>>> >>>>>>> -qq Really quiet feedback. Same as: --feedback >>>>>>> silent >>>>>>> >>>>>>> -v Verbose feedback. Same as: --feedback >>>>>>> verbose >>>>>>> >>>>>>> -J Pass directly to the runtime system. >>>>>>> >>>>>>> -R Pass to the remote runtime system. >>>>>>> >>>>>>> --help Print this synopsis of standard options >>>>>>> -help >>>>>>> -h >>>>>>> >>>>>>> -version Version information >>>>>>> --version >>>>>>> >>>>>>> -fullversion Full Version information >>>>>>> --fullversion >>>>>> >>>>>> >>>>>> ?? --full-version ?? >>>>> >>>>> >>>>> Probably, y. >>>>> >>>>> Thanks much, >>>>> Robert >>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Robert >>>>> >>>>> >> > From michael.mueller at mueller-bruehl.de Wed Aug 17 07:05:48 2016 From: michael.mueller at mueller-bruehl.de (=?ISO-8859-1?Q?Michael_M=FCller?=) Date: Wed, 17 Aug 2016 09:05:48 +0200 Subject: jshell tool: opinions sought -- double-dash long-form command-line options In-Reply-To: <57B3F9CC.9090002@oracle.com> References: <57B2A638.3000909@oracle.com> <57B32C41.6090208@oracle.com> <0D268E17-86B2-4145-BEFD-B6783E231056@oracle.com> <57B3474E.6030102@oracle.com> <57B34B09.2020502@oracle.com> <57B3F9CC.9090002@oracle.com> Message-ID: <216C0CE9-9650-49FE-9E8B-735422D45037@mueller-bruehl.de> Hi Robert, What about Java itself? java -version Thus, keep it. Keep -cp ... --class-path ... But elimate -classpath ... Just my 2cts -- Herzliche Gr??e, Best regards Michael M?ller Twitter: @muellermi Blog: blog.mueller-bruehl.de Web Development with Java and JSF: leanpub.com/jsf Java Lambdas and Parallel Streams: leanpub.com/lambdas Am 17. August 2016 07:44:44 MESZ, schrieb Robert Field : >If jmods does not support legacy single-dash multiple-letter options, >then should jshell? > >Should we trim it down to -- > > --class-path Specify where to find user class files > > --module-path ... directory of modules. > -p > > --upgrade-module-path ... directory of modules that >replace upgradeable modules > > --add-modules [,...] root modules to resolve > > --startup One run replacement for the start-up definitions > > --no-startup Do not run the start-up definitions > -n > > --feedback Specify the initial feedback mode. The mode >may be > predefined (silent, concise, normal, or >verbose) or > previously user-defined > > -q Quiet feedback. Same as: --feedback concise > > -s Really quiet feedback. Same as: --feedback silent > > -v Verbose feedback. Same as: --feedback verbose > > -J Pass directly to the runtime system. > > -R Pass to the remote runtime system. > > --help Print this synopsis of standard options > -h > > --version Version information > > --full-version Full Version information > >Eliminating -- > > -classpath Specify where to find user class files > -cp > > -help Print this synopsis of standard options > > -version Version information > > -fullversion Full Version information > >Note: -qq is switched to -s. And, per Jon's suggestion, changed the >spelling of --no-startup and --full-version to include separating >dashes. > >With this, single-letter options could be combined: e.g. -nq > >-Robert > >On 08/16/16 10:19, Jonathan Gibbons wrote: >> Ben, >> >> The argument about consistency between tools was intended to be >> specific to the syntax and semantics of specific options, like >> --class-path, --module-path, --add-modules, etc. >> >> I didn't mean it to extend to "all ways of specifying a classpath", >as >> in "--class-path", "-classpath", and "-cp". >> >> jmods, for example, is a new tool, that only supports --class-path >> (not -classpath, -cp) >> >> -- Jon >> >> On 08/16/2016 10:12 AM, Ben Evans wrote: >>> +1 to not mixing options. >>> >>> +1 to using JOptSimple >>> >>> It's also worth pointing out that one at least one major supported >>> platform (Mac), the shortcuts are not all present by default, so >while >>> one can just say "javac" and it works, "jshell" (or "jjs") do not >work >>> out of the box. This is apparently due to legacy Apple packaging >>> requirements that we can do nothing about, and is highly annoying. >>> >>> However, it does weaken the argument that arguments should be >entirely >>> consistent between tools, because the end user would have had to >>> engage in a certain amout of platform hackery to make jshell work in >>> the same way as the rest of the pre-Java 7 tools in $JAVA_HOME/bin >>> >>> I'd therefore argue that this is evidence in support of dropping the >>> older-style of options and using the modern double-dash style as the >>> default, along with whatever shortcuts / additional accommodations >>> make sense. >>> >>> Just my 2c, >>> >>> Ben >>> >>> On Tue, Aug 16, 2016 at 10:33 PM, Jonathan Gibbons >>> wrote: >>>> Other new tools are using JOptSimple, so that is certainly a >reasonable >>>> route, but that would (probably) imply dropping old-style options >like >>>> -classpath and -cp. For a new tool, that would be very reasonable. >>>> >>>> I agree that mixing old-style options and combined single letter >>>> options is >>>> a bad idea. >>>> >>>> -- Jon >>>> >>>> >>>> On 08/16/2016 09:47 AM, Robert Field wrote: >>>> >>>>>> On Aug 16, 2016, at 8:07 AM, Jonathan Gibbons >>>>>> > >>>>>> wrote: >>>>>> >>>>>> Robert, >>>>>> >>>>>> Strong input: options that are common across tools should be the > >>>>>> same >>>>>> across tools, for example, the set of module options. You're >already >>>>>> suggesting that, so that's good. >>>>>> >>>>>> Additional input: double-dash options are typically a short >series of >>>>>> words separated by hyphens (instead of concatenated words), so >>>>>> that makes >>>>>> for --no-startup instead of ?nostartup. >>>>> >>>>> Ah! Good point. >>>>> >>>>>> Note that double-dash options should allow '=' as a separator >>>>>> instead of >>>>>> white-space, as in --class-path=my:class:path >>>>>> This is not typically spelled out in detail in command line help, >but >>>>>> there is typically a footnote to that effect at the end of the >help. >>>>> >>>>> Right. I was pointed at JOpt-Simple since it does option parsing. > I >>>>> don?t think I?ll use it since error handling seems to lack the >>>>> control I >>>>> need. But, from that, I saw the =arg requirement. That should be > >>>>> easy to >>>>> hand-craft. >>>>> >>>>> It also allows combining single-letter single-dash options, like >-nq >>>>> instead of -n -q. Given the multi-letter single-dash options, I?m > >>>>> not sure >>>>> that makes sense to do. >>>>> >>>>> (continued) >>>>> >>>>>> -- Jon >>>>>> >>>>>> On 08/15/2016 10:35 PM, Robert Field wrote: >>>>>>> We would like the jshell tool to roll-out using the more modern >>>>>>> double-dash options. Note though that it will ship in the >>>>>>> jdk/bin directory >>>>>>> where almost all commands use legacy option formats. >>>>>>> >>>>>>> Below I propose options for jshell, as this is not a >black-and-white >>>>>>> decision, I'd very much like input.... >>>>>>> >>>>>>> Current jshell options are -- >>>>>>> >>>>>>> -classpath Specify where to find user class files >>>>>>> -cp Specify where to find user class files >>>>>>> -startup One run replacement for the start-up >>>>>>> definitions >>>>>>> -nostartup Do not run the start-up definitions >>>>>>> -feedback Specify the initial feedback mode. The >>>>>>> mode may >>>>>>> be >>>>>>> predefined (silent, concise, normal, or > >>>>>>> verbose) >>>>>>> or >>>>>>> previously user-defined >>>>>>> -q Quiet feedback. Same as: -feedback >concise >>>>>>> -qq Really quiet feedback. Same as: >-feedback >>>>>>> silent >>>>>>> -v Verbose feedback. Same as: -feedback >>>>>>> verbose >>>>>>> -J Pass directly to the runtime >system. >>>>>>> Use one -J for each runtime flag or >flag >>>>>>> argument >>>>>>> -R Pass to the remote runtime >system. >>>>>>> Use one -R for each remote flag or flag > >>>>>>> argument >>>>>>> -help Print this synopsis of standard options >>>>>>> -version Version information >>>>>>> -fullversion Full Version information >>>>>>> >>>>>>> java options are mostly single-dash options, the current >double-dash >>>>>>> options are -- >>>>>>> >>>>>>> -cp >>>>>>> -classpath files> >>>>>>> --class-path >>>>>> files> >>>>>>> A : separated list of directories, JAR >archives, >>>>>>> and ZIP archives to search for class files. >>>>>>> -p >>>>>>> --module-path ... >>>>>>> A : separated list of directories, each >directory >>>>>>> is a directory of modules. >>>>>>> --upgrade-module-path ... >>>>>>> A : separated list of directories, each >directory >>>>>>> is a directory of modules that replace >upgradeable >>>>>>> modules in the runtime image >>>>>>> -m [/] >>>>>>> --module [/] >>>>>>> the initial module to resolve, and the name of > >>>>>>> the main >>>>>>> class >>>>>>> to execute if not specified by the module >>>>>>> --add-modules [,...] >>>>>>> root modules to resolve in addition to the >initial >>>>>>> module. >>>>>>> can also be ALL-DEFAULT, >ALL-SYSTEM, >>>>>>> ALL-MODULE-PATH. >>>>>>> --limit-modules [,...] >>>>>>> limit the universe of observable modules >>>>>>> --list-modules [[,...]] >>>>>>> list the observable modules and exit >>>>>>> --dry-run create VM but do not execute main method. >>>>>>> This --dry-run option may be useful for >>>>>>> validating the >>>>>>> command-line options such as the module system >>>>>>> configuration. >>>>>>> >>>>>>> Of these, --class-path, --module-path, --add-modules, and maybe >>>>>>> --upgrade-module-path seem appropriate for jshell. >>>>>>> >>>>>>> Proposed for jshell -- >>>>>>> >>>>>>> -classpath Specify where to find user class files >>>>>>> -cp >>>>>>> --class-path >>>>>>> >>>>>>> -p directory of modules. >>>>>>> --module-path ... >>>>>>> >>>>>>> --upgrade-module-path ... directory of modules >that >>>>>>> replace upgradeable modules >>>>>>> >>>>>>> --add-modules [,...] root modules to > >>>>>>> resolve >>>>>>> >>>>>>> --startup One run replacement for the start-up >>>>>>> definitions >>>>>>> >>>>>>> --nostartup Do not run the start-up definitions >>>>>> >>>>>> Would be better as --no-startup >>>>> >>>>> Y >>>>> >>>>>>> -n >>>>>>> >>>>>>> --feedback Specify the initial feedback mode. The > >>>>>>> mode may >>>>>>> be >>>>>>> predefined (silent, concise, normal, or > >>>>>>> verbose) >>>>>>> or >>>>>>> previously user-defined >>>>>>> >>>>>>> -q Quiet feedback. Same as: --feedback >>>>>>> concise >>>>>>> >>>>>>> -qq Really quiet feedback. Same as: >--feedback >>>>>>> silent >>>>>>> >>>>>>> -v Verbose feedback. Same as: --feedback >>>>>>> verbose >>>>>>> >>>>>>> -J Pass directly to the runtime >system. >>>>>>> >>>>>>> -R Pass to the remote runtime >system. >>>>>>> >>>>>>> --help Print this synopsis of standard >options >>>>>>> -help >>>>>>> -h >>>>>>> >>>>>>> -version Version information >>>>>>> --version >>>>>>> >>>>>>> -fullversion Full Version information >>>>>>> --fullversion >>>>>> >>>>>> ?? --full-version ?? >>>>> >>>>> Probably, y. >>>>> >>>>> Thanks much, >>>>> Robert >>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Robert >>>>> >> From robert.field at oracle.com Wed Aug 17 19:35:11 2016 From: robert.field at oracle.com (Robert Field) Date: Wed, 17 Aug 2016 12:35:11 -0700 Subject: jshell tool: opinions sought -- double-dash long-form command-line options In-Reply-To: <216C0CE9-9650-49FE-9E8B-735422D45037@mueller-bruehl.de> References: <57B2A638.3000909@oracle.com> <57B32C41.6090208@oracle.com> <0D268E17-86B2-4145-BEFD-B6783E231056@oracle.com> <57B3474E.6030102@oracle.com> <57B34B09.2020502@oracle.com> <57B3F9CC.9090002@oracle.com> <216C0CE9-9650-49FE-9E8B-735422D45037@mueller-bruehl.de> Message-ID: <5F48B28E-E1AF-4478-A362-1F4AC08D03EE@oracle.com> I believe the reasonable choices are: (1) Kitch-sink: support new options with modern syntax and legacy options in legacy syntax and modern syntax. Disallow combined options. (2) Clean modern: Like jmod. All double-dash multiple-letter or single-dash single-letter. Allow combined single-letter options. -Robert > On Aug 17, 2016, at 12:05 AM, Michael M?ller wrote: > > Hi Robert, > > What about Java itself? > > java -version > > Thus, keep it. > > Keep > -cp ... > --class-path ... > But elimate > -classpath ... > > Just my 2cts > -- > Herzliche Gr??e, Best regards > Michael M?ller > > Twitter: @muellermi > Blog: blog.mueller-bruehl.de > Web Development with Java and JSF: leanpub.com/jsf > Java Lambdas and Parallel Streams: leanpub.com/lambdas > > > Am 17. August 2016 07:44:44 MESZ, schrieb Robert Field : > If jmods does not support legacy single-dash multiple-letter options, > then should jshell? > > Should we trim it down to -- > > --class-path Specify where to find user class files > > --module-path ... directory of modules. > -p > > --upgrade-module-path ... directory of modules that > replace upgradeable modules > > --add-modules [,...] root modules to resolve > > --startup One run replacement for the start-up definitions > > --no-startup Do not run the start-up definitions > -n > > --feedback Specify the initial feedback mode. The mode > may be > predefined (silent, concise, normal, or > verbose) or > previously > user-defined > > -q Quiet feedback. Same as: --feedback concise > > -s Really quiet feedback. Same as: --feedback silent > > -v Verbose feedback. Same as: --feedback verbose > > -J Pass directly to the runtime system. > > -R Pass to the remote runtime system. > > --help Print this synopsis of standard options > -h > > --version Version information > > --full-version Full Version information > > Eliminating -- > > -classpath Specify where to find user class files > -cp > > -help Print this synopsis of standard options > > -version Version information > > -fullversion Full Version information > Note: -qq is switched to -s. And, per Jon's suggestion, changed the > spelling of --no-startup and --full-version to include separating dashes. > > With this, single-letter options could be combined: e.g. -nq > > -Robert > > On 08/16/16 10:19, Jonathan Gibbons wrote: > Ben, > > The argument about consistency between tools was intended to be > specific to the syntax and semantics of specific options, like > --class-path, --module-path, --add-modules, etc. > > I didn't mean it to extend to "all ways of specifying a classpath", as > in "--class-path", "-classpath", and "-cp". > > jmods, for example, is a new tool, that only supports --class-path > (not -classpath, -cp) > > -- Jon > > On 08/16/2016 10:12 AM, Ben Evans wrote: > +1 to not mixing options. > > +1 to using JOptSimple > > It's also worth pointing out that one at least one major supported > platform (Mac), the shortcuts are not all present by default, so while > one can just say "javac" and it works, "jshell" (or "jjs") do not work > out of the box. This is apparently due to legacy Apple packaging > requirements that we can do nothing about, and is highly annoying. > > However, it does weaken the argument that arguments should be entirely > consistent between tools, because the end user would have had to > engage in a certain amout of platform hackery to make jshell work in > the same way as the rest of the pre-Java 7 tools in $JAVA_HOME/bin > > I'd therefore argue that this is evidence in support of dropping the > older-style of options and using the modern double-dash style as the > default, along with > whatever shortcuts / additional accommodations > make sense. > > Just my 2c, > > Ben > > On Tue, Aug 16, 2016 at 10:33 PM, Jonathan Gibbons > wrote: > Other new tools are using JOptSimple, so that is certainly a reasonable > route, but that would (probably) imply dropping old-style options like > -classpath and -cp. For a new tool, that would be very reasonable. > > I agree that mixing old-style options and combined single letter > options is > a bad idea. > > -- Jon > > > On 08/16/2016 09:47 AM, Robert Field wrote: > > On Aug 16, 2016, at 8:07 AM, Jonathan Gibbons > > > wrote: > > Robert, > > Strong input: options that are common across tools should be the > same > across tools, for example, the set of module options. You're already > suggesting that, so that's good. > > Additional input: double-dash options are typically a short series of > words separated by hyphens (instead of concatenated words), so > that makes > for --no-startup instead of ?nostartup. > > Ah! Good point. > > Note that double-dash options should allow '=' as a separator > instead of > white-space, as in --class-path=my:class:path > This is not typically spelled out in detail in command line help, but > there is t! > ypically > a footnote to that effect at the end of the help. > > Right. I was pointed at JOpt-Simple since it does option parsing. I > don?t think I?ll use it since error handling seems to lack the > control I > need. But, from that, I saw the =arg requirement. That should be > easy to > hand-craft. > > It also allows combining single-letter single-dash options, like -nq > instead of -n -q. Given the multi-letter single-dash options, I?m > not sure > that makes sense to do. > > (continued) > > -- Jon > > On 08/15/2016 10:35 PM, Robert Field wrote: > We would like the jshell tool to roll-out using the more modern > double-dash options. Note though that! > it will > ship in the > jdk/bin directory > where almost all commands use legacy option formats. > > Below I propose options for jshell, as this is not a black-and-white > decision, I'd very much like input.... > > Current jshell options are -- > > -classpath Specify where to find user class files > -cp Specify where to find user class files > -startup One run replacement for the start-up > definitions > -nostartup Do not run the start-up definitions > -feedback Specify the initial feedback mode. The > mode may > be > predefined (silent, concise, normal, or > verbose) > or > previously user-defined > -q Quiet feedback. Same as: -feedback concise > -qq Really quiet feedback. Same as: -feedback > > silent > -v Verbose feedback. Same as: -feedback > verbose > -J Pass directly to the runtime system. > Use one -J for each runtime flag or flag > argument > -R Pass to the remote runtime system. > Use one -R for each remote flag or flag > argument > -help Print this synopsis of standard options > -version Version information > -fullversion Full Version information > > java options are mostly single-dash options, the current double-dash > options are -- > > -cp > -classpath > --class-path files> > ! > A : > separated list of directories, JAR archives, > and ZIP archives to search for class files. > -p > --module-path ... > A : separated list of directories, each directory > is a directory of modules. > --upgrade-module-path ... > A : separated list of directories, each directory > is a directory of modules that replace upgradeable > modules in the runtime image > -m [/] > --module [/] > the initial module to resolve, and the name of > the main > class > to execute if not specified by the module > --add-modules [,...] > root modules to resolve in addition to the initial > module. > can also be ALL-DEFAULT, ALL-SYSTEM, > ALL-MODULE-PATH. > --limit-modules [,...] > limit the universe of observable modules > --list-modules [[,...]] > list the observable modules and exit > --dry-run create VM but do not execute main method. > This --dry-run option may be useful for > validating the > command-line options such as the module system > configuration. > > Of these, --class-path, --module-path, --add-modules, and maybe > --upgrade-module-path seem appropriate for jshell. > > Proposed for jshell -- > > -classpath Specify where to find user class files > -cp > --class-path > > -p ! > > directory of modules. > --module-path ... > > --upgrade-module-path ... directory of modules that > replace upgradeable modules > > --add-modules [,...] root modules to > resolve > > --startup One run replacement for the start-up > definitions > > --nostartup Do not run the start-up definitions > > Would be better as --no-startup > > Y > > -n > > --feedback Specify the initial feedback mode. The > mode may > be > predefined (silent, concise, normal, or > verb! > ose) > or > previously user-defined > > -q Quiet feedback. Same as: --feedback > concise > > -qq Really quiet feedback. Same as: --feedback > silent > > -v Verbose feedback. Same as: --feedback > verbose > > -J Pass directly to the runtime system. > > -R Pass to the remote runtime system. > > --help Print this synopsis of standard options > -help > -h > > -version Version information > --version > > -fullversion Full Version information > --fullversion > > ?? --full-version ?? > > Probably, y. > > Thanks much, > Robert > > > Thanks, > Robert > > > From jonathan.gibbons at oracle.com Wed Aug 17 19:44:03 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 17 Aug 2016 12:44:03 -0700 Subject: jshell tool: opinions sought -- double-dash long-form command-line options In-Reply-To: <5F48B28E-E1AF-4478-A362-1F4AC08D03EE@oracle.com> References: <57B2A638.3000909@oracle.com> <57B32C41.6090208@oracle.com> <0D268E17-86B2-4145-BEFD-B6783E231056@oracle.com> <57B3474E.6030102@oracle.com> <57B34B09.2020502@oracle.com> <57B3F9CC.9090002@oracle.com> <216C0CE9-9650-49FE-9E8B-735422D45037@mueller-bruehl.de> <5F48B28E-E1AF-4478-A362-1F4AC08D03EE@oracle.com> Message-ID: <57B4BE83.50508@oracle.com> For new code, I think 2 is to be preferred, with an optional minor allowance for alternate forms of --help. But a clean modern 2 is OK too. -- Jon On 08/17/2016 12:35 PM, Robert Field wrote: > I believe the reasonable choices are: > > (1) Kitch-sink: support new options with modern syntax and legacy > options in legacy syntax and modern syntax. Disallow combined options. > > (2) Clean modern: Like jmod. All double-dash multiple-letter or > single-dash single-letter. Allow combined single-letter options. > > -Robert > > > >> On Aug 17, 2016, at 12:05 AM, Michael M?ller >> > > wrote: >> >> Hi Robert, >> >> What about Java itself? >> >> java -version >> >> Thus, keep it. >> >> Keep >> -cp ... >> --class-path ... >> But elimate >> -classpath ... >> >> Just my 2cts >> -- >> Herzliche Gr??e, Best regards >> Michael M?ller >> >> Twitter: @muellermi >> Blog: blog.mueller-bruehl.de >> Web Development with Java and JSF: leanpub.com/jsf >> >> Java Lambdas and Parallel Streams: leanpub.com/lambdas >> >> >> >> Am 17. August 2016 07:44:44 MESZ, schrieb Robert Field >> >: >> >> If jmods does not support legacy single-dash multiple-letter options, >> then should jshell? >> >> Should we trim it down to -- >> >> --class-path Specify where to find user class files >> >> --module-path ... directory of modules. >> -p >> >> --upgrade-module-path ... directory of modules that >> replace upgradeable modules >> >> --add-modules [,...] root modules to resolve >> >> --startup One run replacement for the start-up definitions >> >> --no-startup Do not run the start-up definitions >> -n >> >> --feedback Specify the initial feedback mode. The mode >> may be >> predefined (silent, concise, normal, or >> verbose) or >> previously >> user-defined >> >> -q Quiet feedback. Same as: --feedback concise >> >> -s Really quiet feedback. Same as: --feedback silent >> >> -v Verbose feedback. Same as: --feedback verbose >> >> -J Pass directly to the runtime system. >> >> -R Pass to the remote runtime system. >> >> --help Print this synopsis of standard options >> -h >> >> --version Version information >> >> --full-version Full Version information >> >> Eliminating -- >> >> -classpath Specify where to find user class files >> -cp >> >> -help Print this synopsis of standard options >> >> -version Version information >> >> -fullversion Full Version information >> Note: -qq is switched to -s. And, per Jon's suggestion, changed the >> spelling of --no-startup and --full-version to include separating dashes. >> >> With this, single-letter options could be combined: e.g. -nq >> >> -Robert >> >> On 08/16/16 10:19, Jonathan Gibbons wrote: >> >> Ben, The argument about consistency between tools was >> intended to be specific to the syntax and semantics of >> specific options, like --class-path, --module-path, >> --add-modules, etc. I didn't mean it to extend to "all ways >> of specifying a classpath", as in "--class-path", >> "-classpath", and "-cp". jmods, for example, is a new tool, >> that only supports --class-path (not -classpath, -cp) -- Jon >> On 08/16/2016 10:12 AM, Ben Evans wrote: >> >> +1 to not mixing options. +1 to using JOptSimple It's >> also worth pointing out that one at least one major >> supported platform (Mac), the shortcuts are not all >> present by default, so while one can just say "javac" and >> it works, "jshell" (or "jjs") do not work out of the box. >> This is apparently due to legacy Apple packaging >> requirements that we can do nothing about, and is highly >> annoying. However, it does weaken the argument that >> arguments should be entirely consistent between tools, >> because the end user would have had to engage in a >> certain amout of platform hackery to make jshell work in >> the same way as the rest of the pre-Java 7 tools in >> $JAVA_HOME/bin I'd therefore argue that this is evidence >> in support of dropping the older-style of options and >> using the modern double-dash style as the default, along >> with whatever shortcuts / additional accommodations make >> sense. Just my 2c, Ben On Tue, Aug 16, 2016 at 10:33 PM, >> Jonathan Gibbons > > wrote: >> >> Other new tools are using JOptSimple, so that is >> certainly a reasonable route, but that would >> (probably) imply dropping old-style options like >> -classpath and -cp. For a new tool, that would be >> very reasonable. I agree that mixing old-style >> options and combined single letter options is a bad >> idea. -- Jon On 08/16/2016 09:47 AM, Robert Field wrote: >> >> On Aug 16, 2016, at 8:07 AM, Jonathan Gibbons >> > >> > wrote: >> Robert, Strong input: options that are common >> across tools should be the same across tools, >> for example, the set of module options. >> You're already suggesting that, so that's >> good. Additional input: double-dash options >> are typically a short series of words >> separated by hyphens (instead of concatenated >> words), so that makes for --no-startup >> instead of ?nostartup. >> >> Ah! Good point. >> >> Note that double-dash options should allow >> '=' as a separator instead of white-space, as >> in --class-path=my:class:path This is not >> typically spelled out in detail in command >> line help, but there is t! ypically a >> footnote to that effect at the end of the help. >> >> Right. I was pointed at JOpt-Simple since it does >> option parsing. I don?t think I?ll use it since >> error handling seems to lack the control I need. >> But, from that, I saw the =arg requirement. That >> should be easy to hand-craft. It also allows >> combining single-letter single-dash options, like >> -nq instead of -n -q. Given the multi-letter >> single-dash options, I?m not sure that makes >> sense to do. (continued) >> >> -- Jon On 08/15/2016 10:35 PM, Robert Field >> wrote: >> >> We would like the jshell tool to roll-out >> using the more modern double-dash >> options. Note though that! it will ship >> in the jdk/bin directory where almost all >> commands use legacy option formats. Below >> I propose options for jshell, as this is >> not a black-and-white decision, I'd very >> much like input.... Current jshell >> options are -- -classpath Specify >> where to find user class files -cp >> Specify where to find user class files >> -startup One run replacement for >> the start-up definitions -nostartup Do >> not run the start-up definitions >> -feedback Specify the initial >> feedback mode. The mode may be predefined >> (silent, concise, normal, or verbose) or >> previously user-defined -q Quiet >> feedback. Same as: -feedback concise -qq >> Really quiet feedback. Same as: -feedback >> silent -v Verbose feedback. Same as: >> -feedback verbose -J Pass >> directly to the runtime system. Use one >> -J for each runtime flag or flag argument >> -R Pass to the remote >> runtime system. Use one -R for each >> remote flag or flag argument -help Print >> this synopsis of standard options >> -version Version information -fullversion >> Full Version information java options are >> mostly single-dash options, the current >> double-dash options are -- -cp > search path of directories and zip/jar >> files> -classpath > directories and zip/jar files> >> --class-path > directories and zip/jar files> ! A : >> separated list of directories, JAR >> archives, and ZIP archives to search for >> class files. -p >> --module-path ... A : >> separated list of directories, each >> directory is a directory of modules. >> --upgrade-module-path ... A >> : separated list of directories, each >> directory is a directory of modules that >> replace upgradeable modules in the >> runtime image -m [/] >> --module [/] the >> initial module to resolve, and the name >> of the main class to execute if not >> specified by the module --add-modules >> [,...] root >> modules to resolve in addition to the >> initialmodule. can also be >> ALL-DEFAULT, ALL-SYSTEM, ALL-MODULE-PATH. >> --limit-modules >> [,...] limit the >> universe of observable modules >> --list-modules >> [[,...]] list the >> observable modules and exit --dry-run >> create VM but do not execute main method. >> This --dry-run option may be useful for >> validating the command-line options such >> as the module system configuration. Of >> these, --class-path, --module-path, >> --add-modules, and maybe >> --upgrade-module-path seem appropriate >> for jshell. Proposed for jshell -- >> -classpath Specify where to find >> user class files -cp --class-path >> -p ! directory of >> modules. --module-path ... >> --upgrade-module-path ... >> directory of modules that replace >> upgradeable modules --add-modules >> [,...] root >> modules to resolve --startup One >> run replacement for the start-up >> definitions --nostartup Do not run the >> start-up definitions >> >> Would be better as --no-startup >> >> Y >> >> -n --feedback Specify the initial >> feedback mode. The mode may be predefined >> (silent, concise, normal, or verb! ose) >> or previously user-defined -q Quiet >> feedback. Same as: --feedback concise -qq >> Really quiet feedback. Same as: >> --feedback silent -v Verbose feedback. >> Same as: --feedback verbose -J Pass >> directly to the runtime system. >> -R Pass to the remote >> runtime system. --help Print this >> synopsis of standard options -help -h >> -version Version information --version >> -fullversion Full Version information >> --fullversion >> >> ?? --full-version ?? >> >> Probably, y. Thanks much, Robert >> >> Thanks, Robert >> >> > From robert.field at oracle.com Thu Aug 18 07:27:47 2016 From: robert.field at oracle.com (Robert Field) Date: Thu, 18 Aug 2016 00:27:47 -0700 Subject: RFR 8160089: jshell tool: use new double-dash long-form command-line options Message-ID: <57B56373.8020900@oracle.com> Please review.... Bug: https://bugs.openjdk.java.net/browse/JDK-8160089 Webrev Langtools: http://cr.openjdk.java.net/~rfield/8160089v0.webrev/ Webrev JDK: http://cr.openjdk.java.net/~rfield/8160089_jdkv0.webrev/ Thanks, Robert From jonathan.gibbons at oracle.com Thu Aug 18 16:15:47 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 18 Aug 2016 09:15:47 -0700 Subject: jshell tool: opinions sought -- double-dash long-form command-line options In-Reply-To: <57B4C7D4.2030203@oracle.com> References: <57B2A638.3000909@oracle.com> <57B32C41.6090208@oracle.com> <0D268E17-86B2-4145-BEFD-B6783E231056@oracle.com> <57B3474E.6030102@oracle.com> <57B34B09.2020502@oracle.com> <57B3F9CC.9090002@oracle.com> <216C0CE9-9650-49FE-9E8B-735422D45037@mueller-bruehl.de> <5F48B28E-E1AF-4478-A362-1F4AC08D03EE@oracle.com> <57B4BE83.50508@oracle.com> <57B4C7D4.2030203@oracle.com> Message-ID: <57B5DF33.4070500@oracle.com> While I agree that -J is pulled out by the launcher, syntactically -J and -R are both "just" single character options that take a value and fall within the general GNU-style scheme. (But yeah, it starts getting woolly when you start mixing single character options and arguments.) -- Jon On 08/17/2016 01:23 PM, Robert Field wrote: > > On 08/17/16 12:44, Jonathan Gibbons wrote: >> For new code, I think 2 is to be preferred, with an optional minor >> allowance for alternate forms of --help. But a clean modern 2 is OK too. > > -h > > Would be supported > > -help > > Would be a combined option which starts with "-h" so that works too. > > The only remaining niggles are: > > -J Pass directly to the runtime system. > > -R Pass to the remote runtime system. > > > The first of which issupported by the launcher. > > -Robert > > >> >> -- Jon >> >> On 08/17/2016 12:35 PM, Robert Field wrote: >>> I believe the reasonable choices are: >>> >>> (1) Kitch-sink: support new options with modern syntax and legacy >>> options in legacy syntax and modern syntax. Disallow combined options. >>> >>> (2) Clean modern: Like jmod. All double-dash multiple-letter or >>> single-dash single-letter. Allow combined single-letter options. >>> >>> -Robert >>> >>> >>> >>>> On Aug 17, 2016, at 12:05 AM, Michael M?ller >>>> >>> > wrote: >>>> >>>> Hi Robert, >>>> >>>> What about Java itself? >>>> >>>> java -version >>>> >>>> Thus, keep it. >>>> >>>> Keep >>>> -cp ... >>>> --class-path ... >>>> But elimate >>>> -classpath ... >>>> >>>> Just my 2cts >>>> -- >>>> Herzliche Gr??e, Best regards >>>> Michael M?ller >>>> >>>> Twitter: @muellermi >>>> Blog: blog.mueller-bruehl.de >>>> Web Development with Java and JSF: leanpub.com/jsf >>>> >>>> Java Lambdas and Parallel Streams: leanpub.com/lambdas >>>> >>>> >>>> >>>> Am 17. August 2016 07:44:44 MESZ, schrieb Robert Field >>>> >: >>>> >>>> If jmods does not support legacy single-dash multiple-letter options, >>>> then should jshell? >>>> >>>> Should we trim it down to -- >>>> >>>> --class-path Specify where to find user class files >>>> >>>> --module-path ... directory of modules. >>>> -p >>>> >>>> --upgrade-module-path ... directory of modules that >>>> replace upgradeable modules >>>> >>>> --add-modules [,...] root modules to resolve >>>> >>>> --startup One run replacement for the start-up definitions >>>> >>>> --no-startup Do not run the start-up definitions >>>> -n >>>> >>>> --feedback Specify the initial feedback mode. The mode >>>> may be >>>> predefined (silent, concise, normal, or >>>> verbose) or >>>> previously >>>> user-defined >>>> >>>> -q Quiet feedback. Same as: --feedback concise >>>> >>>> -s Really quiet feedback. Same as: --feedback silent >>>> >>>> -v Verbose feedback. Same as: --feedback verbose >>>> >>>> -J Pass directly to the runtime system. >>>> >>>> -R Pass to the remote runtime system. >>>> >>>> --help Print this synopsis of standard options >>>> -h >>>> >>>> --version Version information >>>> >>>> --full-version Full Version information >>>> >>>> Eliminating -- >>>> >>>> -classpath Specify where to find user class files >>>> -cp >>>> >>>> -help Print this synopsis of standard options >>>> >>>> -version Version information >>>> >>>> -fullversion Full Version information >>>> Note: -qq is switched to -s. And, per Jon's suggestion, changed the >>>> spelling of --no-startup and --full-version to include separating dashes. >>>> >>>> With this, single-letter options could be combined: e.g. -nq >>>> >>>> -Robert >>>> >>>> On 08/16/16 10:19, Jonathan Gibbons wrote: >>>> >>>> Ben, The argument about consistency between tools was >>>> intended to be specific to the syntax and semantics of >>>> specific options, like --class-path, --module-path, >>>> --add-modules, etc. I didn't mean it to extend to "all ways >>>> of specifying a classpath", as in "--class-path", >>>> "-classpath", and "-cp". jmods, for example, is a new tool, >>>> that only supports --class-path (not -classpath, -cp) -- >>>> Jon On 08/16/2016 10:12 AM, Ben Evans wrote: >>>> >>>> +1 to not mixing options. +1 to using JOptSimple It's >>>> also worth pointing out that one at least one major >>>> supported platform (Mac), the shortcuts are not all >>>> present by default, so while one can just say "javac" >>>> and it works, "jshell" (or "jjs") do not work out of >>>> the box. This is apparently due to legacy Apple >>>> packaging requirements that we can do nothing about, >>>> and is highly annoying. However, it does weaken the >>>> argument that arguments should be entirely consistent >>>> between tools, because the end user would have had to >>>> engage in a certain amout of platform hackery to make >>>> jshell work in the same way as the rest of the pre-Java >>>> 7 tools in $JAVA_HOME/bin I'd therefore argue that this >>>> is evidence in support of dropping the older-style of >>>> options and using the modern double-dash style as the >>>> default, along with whatever shortcuts / additional >>>> accommodations make sense. Just my 2c, Ben On Tue, Aug >>>> 16, 2016 at 10:33 PM, Jonathan Gibbons >>>> >>> > wrote: >>>> >>>> Other new tools are using JOptSimple, so that is >>>> certainly a reasonable route, but that would >>>> (probably) imply dropping old-style options like >>>> -classpath and -cp. For a new tool, that would be >>>> very reasonable. I agree that mixing old-style >>>> options and combined single letter options is a bad >>>> idea. -- Jon On 08/16/2016 09:47 AM, Robert Field >>>> wrote: >>>> >>>> On Aug 16, 2016, at 8:07 AM, Jonathan >>>> Gibbons >>> >>>> > >>>> wrote: Robert, Strong input: options that >>>> are common across tools should be the same >>>> across tools, for example, the set of >>>> module options. You're already suggesting >>>> that, so that's good. Additional input: >>>> double-dash options are typically a short >>>> series of words separated by hyphens >>>> (instead of concatenated words), so that >>>> makes for --no-startup instead of ?nostartup. >>>> >>>> Ah! Good point. >>>> >>>> Note that double-dash options should allow >>>> '=' as a separator instead of white-space, >>>> as in --class-path=my:class:path This is >>>> not typically spelled out in detail in >>>> command line help, but there is t! ypically >>>> a footnote to that effect at the end of the >>>> help. >>>> >>>> Right. I was pointed at JOpt-Simple since it >>>> does option parsing. I don?t think I?ll use it >>>> since error handling seems to lack the control >>>> I need. But, from that, I saw the =arg >>>> requirement. That should be easy to hand-craft. >>>> It also allows combining single-letter >>>> single-dash options, like -nq instead of -n -q. >>>> Given the multi-letter single-dash options, I?m >>>> not sure that makes sense to do. (continued) >>>> >>>> -- Jon On 08/15/2016 10:35 PM, Robert Field >>>> wrote: >>>> >>>> We would like the jshell tool to >>>> roll-out using the more modern >>>> double-dash options. Note though that! >>>> it will ship in the jdk/bin directory >>>> where almost all commands use legacy >>>> option formats. Below I propose options >>>> for jshell, as this is not a >>>> black-and-white decision, I'd very much >>>> like input.... Current jshell options >>>> are -- -classpath Specify where >>>> to find user class files -cp >>>> Specify where to find user class files >>>> -startup One run replacement for >>>> the start-up definitions -nostartup Do >>>> not run the start-up definitions >>>> -feedback Specify the initial >>>> feedback mode. The mode may be >>>> predefined (silent, concise, normal, or >>>> verbose) or previously user-defined -q >>>> Quiet feedback. Same as: -feedback >>>> concise -qq Really quiet feedback. Same >>>> as: -feedback silent -v Verbose >>>> feedback. Same as: -feedback verbose >>>> -J Pass directly to the >>>> runtime system. Use one -J for each >>>> runtime flag or flag argument -R >>>> Pass to the remote runtime >>>> system. Use one -R for each remote flag >>>> or flag argument -help Print this >>>> synopsis of standard options -version >>>> Version information -fullversion Full >>>> Version information java options are >>>> mostly single-dash options, the current >>>> double-dash options are -- -cp >>> search path of directories and zip/jar >>>> files> -classpath >>> directories and zip/jar files> >>>> --class-path >>> directories and zip/jar files> ! A : >>>> separated list of directories, JAR >>>> archives, and ZIP archives to search >>>> for class files. -p >>>> --module-path ... A : >>>> separated list of directories, each >>>> directory is a directory of modules. >>>> --upgrade-module-path ... >>>> A : separated list of directories, each >>>> directory is a directory of modules >>>> that replace upgradeable modules in the >>>> runtime image -m [/] >>>> --module [/] the >>>> initial module to resolve, and the name >>>> of the main class to execute if not >>>> specified by the module --add-modules >>>> [,...] root >>>> modules to resolve in addition to the >>>> initialmodule. can also be >>>> ALL-DEFAULT, ALL-SYSTEM, >>>> ALL-MODULE-PATH. --limit-modules >>>> [,...] limit >>>> the universe of observable modules >>>> --list-modules >>>> [[,...]] list >>>> the observable modules and exit >>>> --dry-run create VM but do not execute >>>> main method. This --dry-run option may >>>> be useful for validating the >>>> command-line options such as the module >>>> system configuration. Of these, >>>> --class-path, --module-path, >>>> --add-modules, and maybe >>>> --upgrade-module-path seem appropriate >>>> for jshell. Proposed for jshell -- >>>> -classpath Specify where to find >>>> user class files -cp >>>> --class-path -p ! >>>> directory of modules. --module-path >>>> ... --upgrade-module-path >>>> ... directory of modules >>>> that replace upgradeable modules >>>> --add-modules >>>> [,...] root >>>> modules to resolve --startup One >>>> run replacement for the start-up >>>> definitions --nostartup Do not run the >>>> start-up definitions >>>> >>>> Would be better as --no-startup >>>> >>>> Y >>>> >>>> -n --feedback Specify the >>>> initial feedback mode. The mode may be >>>> predefined (silent, concise, normal, or >>>> verb! ose) or previously user-defined >>>> -q Quiet feedback. Same as: --feedback >>>> concise -qq Really quiet feedback. Same >>>> as: --feedback silent -v Verbose >>>> feedback. Same as: --feedback verbose >>>> -J Pass directly to the >>>> runtime system. -R Pass to >>>> the remote runtime system. --help Print >>>> this synopsis of standard options -help >>>> -h -version Version information >>>> --version -fullversion Full Version >>>> information --fullversion >>>> >>>> ?? --full-version ?? >>>> >>>> Probably, y. Thanks much, Robert >>>> >>>> Thanks, Robert >>>> >>>> >>> >> > From robert.field at oracle.com Thu Aug 18 20:09:03 2016 From: robert.field at oracle.com (Robert Field) Date: Thu, 18 Aug 2016 13:09:03 -0700 Subject: RFR 8160089: jshell tool: use new double-dash long-form command-line options In-Reply-To: <57B56373.8020900@oracle.com> References: <57B56373.8020900@oracle.com> Message-ID: <57B615DF.1040904@oracle.com> Updated -- * No changes to non-default property files (thanks Jan) * Better checking for conflicting options * Better testing including of compound options and conflicting options Please review.... Bug: https://bugs.openjdk.java.net/browse/JDK-8160089 Webrev Langtools: http://cr.openjdk.java.net/~rfield/8160089v1.webrev/ Webrev JDK: http://cr.openjdk.java.net/~rfield/8160089_jdkv0.webrev/ Thanks, Robert From robert.field at oracle.com Thu Aug 18 23:00:01 2016 From: robert.field at oracle.com (Robert Field) Date: Thu, 18 Aug 2016 16:00:01 -0700 Subject: RFR 8164277: JShell API: Snippets are immutable and should be available for post-mortem analysis Message-ID: <57B63DF1.7070102@oracle.com> Please review... Bug: https://bugs.openjdk.java.net/browse/JDK-8164277 Webrev: http://cr.openjdk.java.net/~rfield/8164277v0.webrev/ Specdiff: http://cr.openjdk.java.net/~rfield/8164277v0.specdiff/jdk/jshell/JShell.html API: http://cr.openjdk.java.net/~rfield/8164277v0.jshellAPI/jdk/jshell/JShell.html Thanks, Robert From robert.field at oracle.com Fri Aug 19 01:15:44 2016 From: robert.field at oracle.com (Robert Field) Date: Thu, 18 Aug 2016 18:15:44 -0700 Subject: RFR (s) 8158906: JShell: crashes with extremely long result value Message-ID: <57B65DC0.9070605@oracle.com> Please review... Bug: https://bugs.openjdk.java.net/browse/JDK-8158906 Webrev: http://cr.openjdk.java.net/~rfield/8158906v0.webrev/ Thanks, Robert From jan.lahoda at oracle.com Fri Aug 19 08:24:21 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 19 Aug 2016 10:24:21 +0200 Subject: RFR 8164277: JShell API: Snippets are immutable and should be available for post-mortem analysis In-Reply-To: <57B63DF1.7070102@oracle.com> References: <57B63DF1.7070102@oracle.com> Message-ID: <57B6C235.4010705@oracle.com> Seems OK to me. Jan On 19.8.2016 01:00, Robert Field wrote: > Please review... > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8164277 > > Webrev: > http://cr.openjdk.java.net/~rfield/8164277v0.webrev/ > > Specdiff: > http://cr.openjdk.java.net/~rfield/8164277v0.specdiff/jdk/jshell/JShell.html > > > API: > http://cr.openjdk.java.net/~rfield/8164277v0.jshellAPI/jdk/jshell/JShell.html > > > Thanks, > Robert > From jan.lahoda at oracle.com Fri Aug 19 08:33:35 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 19 Aug 2016 10:33:35 +0200 Subject: RFR (s) 8158906: JShell: crashes with extremely long result value In-Reply-To: <57B65DC0.9070605@oracle.com> References: <57B65DC0.9070605@oracle.com> Message-ID: <57B6C45F.6040605@oracle.com> Overall, seems OK to me. Just a couple of minor comments to the test (up to you if you want to change the code or not): -the test constructs a byte array and then constructs a String out of that - any reason why not not simply use a char array? Would seem cleaner to me. -instead of: assertTrue(shut[0] == false, "JShell died with long value"); why not say: assertFalse(shut[0], "JShell died with long value"); (would more cleanly communicate the intent, I think). No need for re-review. Jan On 19.8.2016 03:15, Robert Field wrote: > Please review... > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8158906 > > Webrev: > http://cr.openjdk.java.net/~rfield/8158906v0.webrev/ > > Thanks, > Robert > From bitterfoxc at gmail.com Fri Aug 19 14:22:24 2016 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Fri, 19 Aug 2016 23:22:24 +0900 Subject: RFR (s) 8158906: JShell: crashes with extremely long result value In-Reply-To: <57B65DC0.9070605@oracle.com> References: <57B65DC0.9070605@oracle.com> Message-ID: Hi Robert, I think there is still the problem for Japanese(or Chinese?). Could you try this test case? public void testLongRemoteJapaneseStrings() { //8158906 assertEval("import java.util.stream.*;"); assertEval("String m(int x) { return Stream.generate(() -> \"\u3042\").limit(x).collect(Collectors.joining()); }"); boolean[] shut = new boolean[1]; getState().onShutdown(j -> {shut[0] = true;} ); List el = assertEval("m(65600);"); assertTrue(shut[0] == false, "JShell died with long value"); assertEquals(el.size(), 1, "Excepted one event"); assertTrue(el.get(0).value().length() > 30000, "Expected truncated but long String, got: " + el.get(0).value()); } "\u3042" is the first japanese character, ?(a) and it could be 3 bytes in utf-8. ( https://docs.oracle.com/javase/8/docs/api/java/io/DataOutput.html#writeUTF-java.lang.String- ) I think it isn't yet resolved due to your code limit String to about 30000 characters. i.e. the byte on the stream is still over about 60000. If the test case pass, LGTM! Regards, shinyafox(Shinya Yoshida) 2016-08-19 10:15 GMT+09:00 Robert Field : > Please review... > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8158906 > > Webrev: > http://cr.openjdk.java.net/~rfield/8158906v0.webrev/ > > Thanks, > Robert > > From bitterfoxc at gmail.com Fri Aug 19 14:33:50 2016 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Fri, 19 Aug 2016 23:33:50 +0900 Subject: RFR (s) 8158906: JShell: crashes with extremely long result value In-Reply-To: References: <57B65DC0.9070605@oracle.com> Message-ID: Hi Robert, FYI, here is the old thread to try solving the same problem with this: http://mail.openjdk.java.net/pipermail/kulla-dev/2015-April/000407.html In this thread, we try to use writeObject instead of writeUTF or to omit the string to 800 length like Scala does. Regards, shinyafox(Shinya Yoshida) 2016-08-19 23:22 GMT+09:00 ShinyaYoshida : > Hi Robert, > I think there is still the problem for Japanese(or Chinese?). > > Could you try this test case? > public void testLongRemoteJapaneseStrings() { //8158906 > assertEval("import java.util.stream.*;"); > assertEval("String m(int x) { return Stream.generate(() -> > \"\u3042\").limit(x).collect(Collectors.joining()); }"); > boolean[] shut = new boolean[1]; > getState().onShutdown(j -> {shut[0] = true;} ); > List el = assertEval("m(65600);"); > assertTrue(shut[0] == false, "JShell died with long value"); > assertEquals(el.size(), 1, "Excepted one event"); > assertTrue(el.get(0).value().length() > 30000, > "Expected truncated but long String, got: " + > el.get(0).value()); > } > > "\u3042" is the first japanese character, ?(a) and it could be 3 bytes in > utf-8. > ( https://docs.oracle.com/javase/8/docs/api/java/io/ > DataOutput.html#writeUTF-java.lang.String- ) > I think it isn't yet resolved due to your code limit String to about 30000 > characters. > i.e. the byte on the stream is still over about 60000. > > If the test case pass, LGTM! > > Regards, > shinyafox(Shinya Yoshida) > > > 2016-08-19 10:15 GMT+09:00 Robert Field : > >> Please review... >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8158906 >> >> Webrev: >> http://cr.openjdk.java.net/~rfield/8158906v0.webrev/ >> >> Thanks, >> Robert >> >> > From jan.lahoda at oracle.com Fri Aug 19 15:14:10 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 19 Aug 2016 17:14:10 +0200 Subject: RFR 8160089: jshell tool: use new double-dash long-form command-line options In-Reply-To: <57B615DF.1040904@oracle.com> References: <57B56373.8020900@oracle.com> <57B615DF.1040904@oracle.com> Message-ID: <57B72242.9060208@oracle.com> Seems OK to me. Jan On 18.8.2016 22:09, Robert Field wrote: > Updated -- > * No changes to non-default property files (thanks Jan) > * Better checking for conflicting options > * Better testing including of compound options and conflicting options > > Please review.... > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8160089 > > Webrev Langtools: > http://cr.openjdk.java.net/~rfield/8160089v1.webrev/ > > Webrev JDK: > http://cr.openjdk.java.net/~rfield/8160089_jdkv0.webrev/ > > Thanks, > Robert > > > From robert.field at oracle.com Fri Aug 19 15:55:27 2016 From: robert.field at oracle.com (Robert Field) Date: Fri, 19 Aug 2016 08:55:27 -0700 Subject: RFR (s) 8158906: JShell: crashes with extremely long result value In-Reply-To: References: <57B65DC0.9070605@oracle.com> Message-ID: <156a3839d98.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> Thanks shinyafox! Testing string length doesn't cover actual encoded UTF-8 length. Which can be four bytes. I should include a test with four bytes. And the check should be correspondingly for a smaller number. Thanks, Robert On August 19, 2016 7:22:34 AM ShinyaYoshida wrote: > Hi Robert, > I think there is still the problem for Japanese(or Chinese?). > > Could you try this test case? > public void testLongRemoteJapaneseStrings() { //8158906 > assertEval("import java.util.stream.*;"); > assertEval("String m(int x) { return Stream.generate(() -> > \"\u3042\").limit(x).collect(Collectors.joining()); }"); > boolean[] shut = new boolean[1]; > getState().onShutdown(j -> {shut[0] = true;} ); > List el = assertEval("m(65600);"); > assertTrue(shut[0] == false, "JShell died with long value"); > assertEquals(el.size(), 1, "Excepted one event"); > assertTrue(el.get(0).value().length() > 30000, > "Expected truncated but long String, got: " + > el.get(0).value()); > } > > "\u3042" is the first japanese character, ?(a) and it could be 3 bytes in > utf-8. > ( > https://docs.oracle.com/javase/8/docs/api/java/io/DataOutput.html#writeUTF-java.lang.String- > ) > I think it isn't yet resolved due to your code limit String to about 30000 > characters. > i.e. the byte on the stream is still over about 60000. > > If the test case pass, LGTM! > > Regards, > shinyafox(Shinya Yoshida) > > > 2016-08-19 10:15 GMT+09:00 Robert Field : > >> Please review... >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8158906 >> >> Webrev: >> http://cr.openjdk.java.net/~rfield/8158906v0.webrev/ >> >> Thanks, >> Robert >> >> From bitterfoxc at gmail.com Fri Aug 19 17:21:14 2016 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Sat, 20 Aug 2016 02:21:14 +0900 Subject: RFR (s) 8158906: JShell: crashes with extremely long result value In-Reply-To: <156a3839d98.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> References: <57B65DC0.9070605@oracle.com> <156a3839d98.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> Message-ID: Hi Robert, According to [1] [2] [3], it seems to me that it is enough to test for the character which becomes 3bytes in UTF-8. If the unicode character is bigger than uFFFF, the UTF-8 representation of such character technically can be 4 bytes[1]. But such character is represented by combination of 2 char value in Java[2]. ie, 3bytes character of UTF-8 is a possible upper case in 1 Java char value. unicode # of char value in Java # of bytes in UTF-8 # of bytes in UTF-8 for 1 char value in Java u0000-u007F 1 1 1 u0080-u07FF 1 2 2 u0800-uFFFF 1 3 3 u10000- 2 4 2 If we make u10000- character, we have to use Character#highSurrogate and Character#lowSurrogate: jshell> int _4byteInUTF8 = 0x10000 _4byteInUTF8 ==> 65536 jshell> ""+Character.highSurrogate(_4byteInUTF8)+Character.lowSurrogate(_4byteInUTF8) $23 ==> "??" jshell> $23.length() $24 ==> 2 jshell> $23.getBytes().length $26 ==> 4 Regards, shinyafox(Shinya Yoshida) [1]: https://tools.ietf.org/html/rfc3629 [2]: https://docs.oracle.com/javase/8/docs/api/java/lang/Character.html [3]: https://docs.oracle.com/javase/8/docs/api/java/io/DataOutput.html#writeUTF-java.lang.String- 2016-08-20 0:55 GMT+09:00 Robert Field : > Thanks shinyafox! > > Testing string length doesn't cover actual encoded UTF-8 length. Which > can be four bytes. I should include a test with four bytes. And the check > should be correspondingly for a smaller number. > > Thanks, > Robert > > On August 19, 2016 7:22:34 AM ShinyaYoshida wrote: > >> Hi Robert, >> I think there is still the problem for Japanese(or Chinese?). >> >> Could you try this test case? >> public void testLongRemoteJapaneseStrings() { //8158906 >> assertEval("import java.util.stream.*;"); >> assertEval("String m(int x) { return Stream.generate(() -> >> \"\u3042\").limit(x).collect(Collectors.joining()); }"); >> boolean[] shut = new boolean[1]; >> getState().onShutdown(j -> {shut[0] = true;} ); >> List el = assertEval("m(65600);"); >> assertTrue(shut[0] == false, "JShell died with long value"); >> assertEquals(el.size(), 1, "Excepted one event"); >> assertTrue(el.get(0).value().length() > 30000, >> "Expected truncated but long String, got: " + >> el.get(0).value()); >> } >> >> "\u3042" is the first japanese character, ?(a) and it could be 3 bytes in >> utf-8. >> ( https://docs.oracle.com/javase/8/docs/api/java/io/ >> DataOutput.html#writeUTF-java.lang.String- ) >> I think it isn't yet resolved due to your code limit String to about >> 30000 characters. >> i.e. the byte on the stream is still over about 60000. >> >> If the test case pass, LGTM! >> >> Regards, >> shinyafox(Shinya Yoshida) >> >> >> 2016-08-19 10:15 GMT+09:00 Robert Field : >> >>> Please review... >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8158906 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rfield/8158906v0.webrev/ >>> >>> Thanks, >>> Robert >>> >>> >> From robert.field at oracle.com Fri Aug 19 20:03:48 2016 From: robert.field at oracle.com (Robert Field) Date: Fri, 19 Aug 2016 13:03:48 -0700 Subject: RFR (s) 8158906: JShell: crashes with extremely long result value In-Reply-To: <57B65DC0.9070605@oracle.com> References: <57B65DC0.9070605@oracle.com> Message-ID: <57B76624.1060703@oracle.com> Thanks Shinya and Jan for the comments/reviews! I've updated * Changed the max to 2 ^ 16 / 3 -1 * Put that in a constant * Added Shinya's test * Switched to assertFalse * Changed both tests to test edge conditions New webrev: http://cr.openjdk.java.net/~rfield/8158906v1.webrev/ -Robert On 08/18/16 18:15, Robert Field wrote: > Please review... > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8158906 > > Webrev: > http://cr.openjdk.java.net/~rfield/8158906v0.webrev/ > > Thanks, > Robert > From jan.lahoda at oracle.com Fri Aug 19 20:34:49 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 19 Aug 2016 22:34:49 +0200 Subject: RFR (s) 8158906: JShell: crashes with extremely long result value In-Reply-To: <57B76624.1060703@oracle.com> References: <57B65DC0.9070605@oracle.com> <57B76624.1060703@oracle.com> Message-ID: <57B76D69.50005@oracle.com> Seems OK to me. Jan On 19.8.2016 22:03, Robert Field wrote: > Thanks Shinya and Jan for the comments/reviews! > > I've updated > * Changed the max to 2 ^ 16 / 3 -1 > * Put that in a constant > * Added Shinya's test > * Switched to assertFalse > * Changed both tests to test edge conditions > > New webrev: > http://cr.openjdk.java.net/~rfield/8158906v1.webrev/ > > -Robert > > > On 08/18/16 18:15, Robert Field wrote: >> Please review... >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8158906 >> >> Webrev: >> http://cr.openjdk.java.net/~rfield/8158906v0.webrev/ >> >> Thanks, >> Robert >> > From bitterfoxc at gmail.com Fri Aug 19 23:21:54 2016 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Sat, 20 Aug 2016 08:21:54 +0900 Subject: RFR (s) 8158906: JShell: crashes with extremely long result value In-Reply-To: <57B76624.1060703@oracle.com> References: <57B65DC0.9070605@oracle.com> <57B76624.1060703@oracle.com> Message-ID: LGTM!! Thank you, shinyafox(Shinya Yoshida) 2016/08/20 ??5:04 "Robert Field" : > Thanks Shinya and Jan for the comments/reviews! > > I've updated > * Changed the max to 2 ^ 16 / 3 -1 > * Put that in a constant > * Added Shinya's test > * Switched to assertFalse > * Changed both tests to test edge conditions > > New webrev: > http://cr.openjdk.java.net/~rfield/8158906v1.webrev/ > > -Robert > > > On 08/18/16 18:15, Robert Field wrote: > >> Please review... >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8158906 >> >> Webrev: >> http://cr.openjdk.java.net/~rfield/8158906v0.webrev/ >> >> Thanks, >> Robert >> >> > From robert.field at oracle.com Sat Aug 20 05:26:52 2016 From: robert.field at oracle.com (Robert Field) Date: Fri, 19 Aug 2016 22:26:52 -0700 Subject: RFR 8164518: JShell: Add failover case of explicitly listening to "localhost" Message-ID: <57B7EA1C.5060409@oracle.com> Please review... Bug: https://bugs.openjdk.java.net/browse/JDK-8164518 Webrev: http://cr.openjdk.java.net/~rfield/8164518v0.webrev/ Specdiff: http://cr.openjdk.java.net/~rfield/8164518v0.specdiff/jdk/jshell/execution/JDIDefaultExecutionControl.html http://cr.openjdk.java.net/~rfield/8164518v0.specdiff/jdk/jshell/execution/JDIInitiator.html API: http://cr.openjdk.java.net/~rfield/8164518v0.jshellAPI/jdk/jshell/execution/package-summary.html Thanks, Robert From robert.field at oracle.com Sun Aug 21 20:33:50 2016 From: robert.field at oracle.com (Robert Field) Date: Sun, 21 Aug 2016 13:33:50 -0700 Subject: RFR 8164518: JShell: Add failover case of explicitly listening to "localhost" In-Reply-To: <57B7EA1C.5060409@oracle.com> References: <57B7EA1C.5060409@oracle.com> Message-ID: <57BA102E.50304@oracle.com> Little update -- * Slightly more general API * Broader testing Please review... Bug: https://bugs.openjdk.java.net/browse/JDK-8164518 Webrev: http://cr.openjdk.java.net/~rfield/8164518v1.webrev/ Specdiff: http://cr.openjdk.java.net/~rfield/8164518v1.specdiff/jdk/jshell/execution/JDIDefaultExecutionControl.html http://cr.openjdk.java.net/~rfield/8164518v1.specdiff/jdk/jshell/execution/JDIInitiator.html API: http://cr.openjdk.java.net/~rfield/8164518v1.jshellAPI/jdk/jshell/execution/package-summary.html Thanks, Robert From robert.field at oracle.com Sun Aug 21 23:19:56 2016 From: robert.field at oracle.com (Robert Field) Date: Sun, 21 Aug 2016 16:19:56 -0700 Subject: RFR 8154374: JShell: setContextClassLoader() / 8080347: jshell tool: /vars when the status is other than Active Message-ID: <57BA371C.9090102@oracle.com> Please review... Bugs: https://bugs.openjdk.java.net/browse/JDK-8154374 https://bugs.openjdk.java.net/browse/JDK-8080347 Webrev: http://cr.openjdk.java.net/~rfield/8154374v0.webrev/ Thanks, Robert From robert.field at oracle.com Mon Aug 22 01:49:20 2016 From: robert.field at oracle.com (Robert Field) Date: Sun, 21 Aug 2016 18:49:20 -0700 Subject: JShell: ideas/opinion sought -- /edit with external editors which return immediately Message-ID: <57BA5A20.9060403@oracle.com> When an external editor has been selected with '/set editor ...' and the /edit command is used: * until the editor exits, no jshell prompt is displayed and no input is accepted * a temp file is created containing the snippets selected for editing * the editor is launched with that temp file as its argument * until the editor exits the jshell tool watches the temp file for changes, entering any changes * when the editor exits, the jshell tool stops watching and the prompt is displayed again Michael Mueller submitted this bug: https://bugs.openjdk.java.net/browse/JDK-8158738 pointing out that this scheme fails for many editors when there is an existing window (gedit, netbeans, nano, emacsclient -n, ...), Here I use gedit to illustrate the issue. What is happening in this case is that the first time the gedit command is used it creates the window and waits for all windows to close before exiting. Subsequent calls to gedit add a pane for the file and return immediately. As a result, where the subsequent call is from a /edit command, the jshell tool assumes the editor has exited, stops watching the file, and queries for input with a prompt. For gedit, this can be addressed by using the --wait or maybe better the --standalone option: /set editor gedit -s There are several ways to resolve this issue: (1) Add documentation to the '/set editor' command describing the requirement that the editor command not return until editing is complete. (2) Change the behaviour of the /edit command to continually watch every temporary file that was ever opened. The concern with this is that then changes could be made from multiple angles at overlapping times: the jshell prompt, and multiple open editors. Changes in one would not be reflected in the others, allowing changes to be smashed. This might be acceptable because the same could occur in other contexts with multiple editors, though there would usually be notifications that the file had changed underneath you. Note: there is no primary "file" with which to do this in the jshell tool -- synthetically manufacturing one would be fraught with data loss peril. Another issue is that output would be coming from multiple threads -- while waiting (or typing) at the jshell prompt you would get notifications about editor changes " modified method m()". (3) If (2) were considered appropriate, then it might be reasonable to take the next step, always return immediately from the /edit command, thus allowing jshell commands while in the editor. (4) Michael Mueller suggests observing the jshell tool keyboard input 'If the user presses Esc within the terminal, the JShell queries "Return to JShell?". If the user answers "y", then the JShell returns to its prompt.' Thoughts? -Robert From michael.mueller at mueller-bruehl.de Mon Aug 22 05:01:23 2016 From: michael.mueller at mueller-bruehl.de (=?UTF-8?Q?Michael_M=c3=bcller?=) Date: Mon, 22 Aug 2016 07:01:23 +0200 Subject: JShell: ideas/opinion sought -- /edit with external editors which return immediately In-Reply-To: <57BA5A20.9060403@oracle.com> References: <57BA5A20.9060403@oracle.com> Message-ID: <213d978c-5c79-ded9-1332-b6afa91b0180@mueller-bruehl.de> +1 for option 4 a) If, and only if the editor process is started from within the JShell then JShell will return to input when the editor process ends. In all cases: if the user starts the /edit then JShell does not accept any input except a special Escape character (e.g. the Esc key) until a) or that special input. In case of that special input JShell queries "Quit edit mode (Yn)?" If the user answers "y", then JShell returns to its prompt. As long as JShell is in "waiting" mode, it observes any change to the file and runs the code snippets if a change is detected. If the editing process is started from within the JShell and the user keys in the escape character, then JShell will stop the editing process. Herzliche Gr??e - Best Regards, Michael M?ller Br?hl, Germany blog.mueller-bruehl.de it-rezension.de @muellermi Read my books "Web Development with Java and JSF": https://leanpub.com/jsf "Java Lambdas und (parallel) Streams" Deutsche Ausgabe: https://leanpub.com/lambdas-de "Java Lambdas and (parallel) Streams" English edition: https://leanpub.com/lambdas On 08/22/2016 03:49 AM, Robert Field wrote: > When an external editor has been selected with '/set editor ...' and > the /edit command is used: > > * until the editor exits, no jshell prompt is displayed and no > input is accepted > * a temp file is created containing the snippets selected for editing > * the editor is launched with that temp file as its argument > * until the editor exits the jshell tool watches the temp file for > changes, entering any changes > * when the editor exits, the jshell tool stops watching and the > prompt is displayed again > > Michael Mueller submitted this bug: > > https://bugs.openjdk.java.net/browse/JDK-8158738 > > pointing out that this scheme fails for many editors when there is an > existing window (gedit, netbeans, nano, emacsclient -n, ...), Here I > use gedit to illustrate the issue. > > What is happening in this case is that the first time the gedit > command is used it creates the window and waits for all windows to > close before exiting. Subsequent calls to gedit add a pane for the > file and return immediately. As a result, where the subsequent call is > from a /edit command, the jshell tool assumes the editor has exited, > stops watching the file, and queries for input with a prompt. > > For gedit, this can be addressed by using the --wait or maybe better > the --standalone option: > > /set editor gedit -s > > There are several ways to resolve this issue: > > (1) Add documentation to the '/set editor' command describing the > requirement that the editor command not return until editing is complete. > > (2) Change the behaviour of the /edit command to continually watch > every temporary file that was ever opened. The concern with this is > that then changes could be made from multiple angles at overlapping > times: the jshell prompt, and multiple open editors. Changes in one > would not be reflected in the others, allowing changes to be smashed. > This might be acceptable because the same could occur in other > contexts with multiple editors, though there would usually be > notifications that the file had changed underneath you. Note: there is > no primary "file" with which to do this in the jshell tool -- > synthetically manufacturing one would be fraught with data loss peril. > Another issue is that output would be coming from multiple threads -- > while waiting (or typing) at the jshell prompt you would get > notifications about editor changes " modified method m()". > > (3) If (2) were considered appropriate, then it might be reasonable to > take the next step, always return immediately from the /edit command, > thus allowing jshell commands while in the editor. > > (4) Michael Mueller suggests observing the jshell tool keyboard input > 'If the user presses Esc within the terminal, the JShell queries > "Return to JShell?". If the user answers "y", then the JShell returns > to its prompt.' > > Thoughts? > > -Robert > > From robert.field at oracle.com Mon Aug 22 08:44:54 2016 From: robert.field at oracle.com (Robert Field) Date: Mon, 22 Aug 2016 01:44:54 -0700 Subject: Kulla-dev: You can join in the discussions Message-ID: <156b16c8370.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> I'm clearing up a confusion I've just discovered that some people have... Kulla-dev is an open discussion forum. If you receive Kulla-dev emails, then you can participate in discussions. Enjoy, Robert From jan.lahoda at oracle.com Mon Aug 22 09:15:22 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 22 Aug 2016 11:15:22 +0200 Subject: RFR JDK-8156911: JShell: file manager should be closed Message-ID: <57BAC2AA.7000309@oracle.com> Hi, Bug: https://bugs.openjdk.java.net/browse/JDK-8156911 The constructor of SourceCodeAnalysisImpl.SourceCache creates a JavaFileManager. It will close it eventually (see SourceCache.closed), but if setLocationFromPaths fails with an exception, the file manager won't be closed. This patch fixes that: http://cr.openjdk.java.net/~jlahoda/8156911/webrev.00/ Does this look OK? Thanks, Jan From jan.lahoda at oracle.com Mon Aug 22 14:50:01 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 22 Aug 2016 16:50:01 +0200 Subject: RFR 8164518: JShell: Add failover case of explicitly listening to "localhost" In-Reply-To: <57B7EA1C.5060409@oracle.com> References: <57B7EA1C.5060409@oracle.com> Message-ID: <57BB1119.8080904@oracle.com> I wonder if the behavior of JDIInitiator should be changed to always consider useLocalhost == true? Is there a case for useLocalHost == false, that cannot be automatically detected? Jan On 20.8.2016 07:26, Robert Field wrote: > Please review... > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8164518 > > Webrev: > http://cr.openjdk.java.net/~rfield/8164518v0.webrev/ > > Specdiff: > http://cr.openjdk.java.net/~rfield/8164518v0.specdiff/jdk/jshell/execution/JDIDefaultExecutionControl.html > > http://cr.openjdk.java.net/~rfield/8164518v0.specdiff/jdk/jshell/execution/JDIInitiator.html > > > API: > http://cr.openjdk.java.net/~rfield/8164518v0.jshellAPI/jdk/jshell/execution/package-summary.html > > > Thanks, > Robert > From jan.lahoda at oracle.com Mon Aug 22 14:51:44 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 22 Aug 2016 16:51:44 +0200 Subject: RFR 8154374: JShell: setContextClassLoader() / 8080347: jshell tool: /vars when the status is other than Active In-Reply-To: <57BA371C.9090102@oracle.com> References: <57BA371C.9090102@oracle.com> Message-ID: <57BB1180.8060002@oracle.com> Seems OK to me. Jan On 22.8.2016 01:19, Robert Field wrote: > Please review... > > Bugs: > https://bugs.openjdk.java.net/browse/JDK-8154374 > https://bugs.openjdk.java.net/browse/JDK-8080347 > > Webrev: > http://cr.openjdk.java.net/~rfield/8154374v0.webrev/ > > Thanks, > Robert > From robert.field at oracle.com Mon Aug 22 15:52:45 2016 From: robert.field at oracle.com (Robert Field) Date: Mon, 22 Aug 2016 08:52:45 -0700 Subject: RFR JDK-8156911: JShell: file manager should be closed In-Reply-To: <57BAC2AA.7000309@oracle.com> References: <57BAC2AA.7000309@oracle.com> Message-ID: <57BB1FCD.7010604@oracle.com> Looks good. -Robert On 08/22/16 02:15, Jan Lahoda wrote: > Hi, > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8156911 > > The constructor of SourceCodeAnalysisImpl.SourceCache creates a > JavaFileManager. It will close it eventually (see SourceCache.closed), > but if setLocationFromPaths fails with an exception, the file manager > won't be closed. This patch fixes that: > http://cr.openjdk.java.net/~jlahoda/8156911/webrev.00/ > > Does this look OK? > > Thanks, > Jan From robert.field at oracle.com Mon Aug 22 17:08:31 2016 From: robert.field at oracle.com (Robert Field) Date: Mon, 22 Aug 2016 10:08:31 -0700 Subject: RFR 8164518: JShell: Add failover case of explicitly listening to "localhost" In-Reply-To: <57BB1119.8080904@oracle.com> References: <57B7EA1C.5060409@oracle.com> <57BB1119.8080904@oracle.com> Message-ID: <57BB318F.60203@oracle.com> On 08/22/16 07:50, Jan Lahoda wrote: > I wonder if the behavior of JDIInitiator should be changed to always > consider useLocalhost == true? Is there a case for useLocalHost == > false, that cannot be automatically detected? Ah! Please see updated fix: http://mail.openjdk.java.net/pipermail/kulla-dev/2016-August/001566.html The parameter is not so weird in that ;-) It is important to still provide access to the loop-back address name determined by JDI, so I don't want to hard-wire "localhost" always. Thanks, Robert > > Jan > > On 20.8.2016 07:26, Robert Field wrote: >> Please review... >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8164518 >> >> Webrev: >> http://cr.openjdk.java.net/~rfield/8164518v0.webrev/ >> >> Specdiff: >> http://cr.openjdk.java.net/~rfield/8164518v0.specdiff/jdk/jshell/execution/JDIDefaultExecutionControl.html >> >> >> http://cr.openjdk.java.net/~rfield/8164518v0.specdiff/jdk/jshell/execution/JDIInitiator.html >> >> >> >> API: >> http://cr.openjdk.java.net/~rfield/8164518v0.jshellAPI/jdk/jshell/execution/package-summary.html >> >> >> >> Thanks, >> Robert >> From jan.lahoda at oracle.com Mon Aug 22 17:46:18 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 22 Aug 2016 19:46:18 +0200 Subject: RFR 8164518: JShell: Add failover case of explicitly listening to "localhost" In-Reply-To: <57BB318F.60203@oracle.com> References: <57B7EA1C.5060409@oracle.com> <57BB1119.8080904@oracle.com> <57BB318F.60203@oracle.com> Message-ID: <57BB3A6A.5070708@oracle.com> Ok, seems OK to me. Jan On 22.8.2016 19:08, Robert Field wrote: > > On 08/22/16 07:50, Jan Lahoda wrote: >> I wonder if the behavior of JDIInitiator should be changed to always >> consider useLocalhost == true? Is there a case for useLocalHost == >> false, that cannot be automatically detected? > > Ah! Please see updated fix: > > http://mail.openjdk.java.net/pipermail/kulla-dev/2016-August/001566.html > > The parameter is not so weird in that ;-) > > It is important to still provide access to the loop-back address name > determined by JDI, so I don't want to hard-wire "localhost" always. > > Thanks, > Robert > >> >> Jan >> >> On 20.8.2016 07:26, Robert Field wrote: >>> Please review... >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8164518 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rfield/8164518v0.webrev/ >>> >>> Specdiff: >>> http://cr.openjdk.java.net/~rfield/8164518v0.specdiff/jdk/jshell/execution/JDIDefaultExecutionControl.html >>> >>> >>> http://cr.openjdk.java.net/~rfield/8164518v0.specdiff/jdk/jshell/execution/JDIInitiator.html >>> >>> >>> >>> API: >>> http://cr.openjdk.java.net/~rfield/8164518v0.jshellAPI/jdk/jshell/execution/package-summary.html >>> >>> >>> >>> Thanks, >>> Robert >>> > From robert.field at oracle.com Thu Aug 25 01:59:54 2016 From: robert.field at oracle.com (Robert Field) Date: Wed, 24 Aug 2016 18:59:54 -0700 Subject: RFR 8158738: jshell tool: Save does not affect jshell if started from another editor Message-ID: <57BE511A.6080506@oracle.com> Please review this fix. Description excerpted from the bug report -- When the /edit command is used, until the editor exits, no jshell prompt is displayed and no input is accepted, during this time the jshell tool watches the temp file for changes, entering any changes. When the editor exits the jshell tool stops watching. From my experiments with gedit, what is happening in this case is that the first time the gedit command is used it creates the window and waits for all windows to close before exiting. Subsequent calls to gedit add a pane for the file and return immediately. As a result the jshell tool assumes the editor has exited, stops watching the file, and queries for input with a prompt. For gedit, this can be addressed by using the --wait or maybe better the --standalone option: /set editor gedit -s However, other editors do not have support for waiting. The implemented solution: Add a "-wait" option to '/set editor' which prompts and waits before transitioning from edit mode. Bug: https://bugs.openjdk.java.net/browse/JDK-8158738 Webrev: http://cr.openjdk.java.net/~rfield/8158738v0.webrev/ Thanks, Robert From jan.lahoda at oracle.com Thu Aug 25 15:23:35 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 25 Aug 2016 17:23:35 +0200 Subject: RFR JDK-8131023: JShell: System.in does not work Message-ID: <57BF0D77.8000901@oracle.com> Hi, Bug: https://bugs.openjdk.java.net/browse/JDK-8131023 Langtools webrev: http://cr.openjdk.java.net/~jlahoda/8131023/langtools.00/ JDK repository webrev: http://cr.openjdk.java.net/~jlahoda/8131023/jdk.00/ Specdiff: http://cr.openjdk.java.net/~jlahoda/8131023/diff.00/jdk/jshell/execution/Util.html Currently jshell forwards output from the agent to the main process. With this patch, the input is also forwarded from the main process to the agent. InputStream.read() is only called in the main process if it has been called on the agent side; this is achieved by using an artificial OutputStream in the agent->main process direction. On the agent side, when an input is requested, a character is written to the corresponding artificial OutputStream, the main process is about that, reads from the actual input and sends the data back to the agent. In the tool, jline is used to actually read the input, as System.in is switched in the raw mode. This requires a tweak in jline, to detect the proper column on which the editing starts, to cover requests like: System.err.print("Prompt: "); System.err.flush(); System.in.read(); Without the tweak, the line editor wouldn't unfortunately know about the text written to the console (for supported terminals, at least). (This tweak may be useful in any case for complex prompts that use escape sequences; also for jjs.) An alternative would be to try to switch jline off while reading the user's input. The advantage of using jline is that it allows to detect Ctrl-C. Any feedback is welcome! Thanks, Jan From robert.field at oracle.com Thu Aug 25 17:37:15 2016 From: robert.field at oracle.com (Robert Field) Date: Thu, 25 Aug 2016 10:37:15 -0700 Subject: RFR JDK-8131023: JShell: System.in does not work In-Reply-To: <57BF0D77.8000901@oracle.com> References: <57BF0D77.8000901@oracle.com> Message-ID: <57BF2CCB.7080406@oracle.com> As the bug title states, System.in does not work from Snippets. In a command line tool there is only one "in", even though the constructor for the tool takes a separate cmdIn and userIn. So, for a command line tool to work these need to be unified. However, though the JShell API is the recommended approach to creating new tools, some will choose to wrap the tool, say in a GUI. In fact this has already been done. Such a wrapped tool can have separate input channels. Rather than changing the constructor for JShellTool to remove the userIn parameter, it would seem to leave more options open if a new constructor with just one input parameter (not named "cmdIn") was added which forwards to the old constructor. More later... On 08/25/16 08:23, Jan Lahoda wrote: > Hi, > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8131023 > > Langtools webrev: > http://cr.openjdk.java.net/~jlahoda/8131023/langtools.00/ > > JDK repository webrev: > http://cr.openjdk.java.net/~jlahoda/8131023/jdk.00/ > > Specdiff: > http://cr.openjdk.java.net/~jlahoda/8131023/diff.00/jdk/jshell/execution/Util.html > > > Currently jshell forwards output from the agent to the main process. > With this patch, the input is also forwarded from the main process to > the agent. InputStream.read() is only called in the main process if it > has been called on the agent side; this is achieved by using an > artificial OutputStream in the agent->main process direction. On the > agent side, when an input is requested, a character is written to the > corresponding artificial OutputStream, the main process is about that, > reads from the actual input and sends the data back to the agent. > > In the tool, jline is used to actually read the input, as System.in is > switched in the raw mode. This requires a tweak in jline, to detect > the proper column on which the editing starts, to cover requests like: > > System.err.print("Prompt: "); System.err.flush(); System.in.read(); > > Without the tweak, the line editor wouldn't unfortunately know about > the text written to the console (for supported terminals, at least). > (This tweak may be useful in any case for complex prompts that use > escape sequences; also for jjs.) > > An alternative would be to try to switch jline off while reading the > user's input. The advantage of using jline is that it allows to detect > Ctrl-C. > > Any feedback is welcome! > > Thanks, > Jan From jan.lahoda at oracle.com Thu Aug 25 19:57:30 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 25 Aug 2016 21:57:30 +0200 Subject: RFR 8158738: jshell tool: Save does not affect jshell if started from another editor In-Reply-To: <57BE511A.6080506@oracle.com> References: <57BE511A.6080506@oracle.com> Message-ID: <57BF4DAA.5000705@oracle.com> Seems OK. Jan On 25.8.2016 03:59, Robert Field wrote: > Please review this fix. Description excerpted from the bug report -- > > When the /edit command is used, until the editor exits, no jshell > prompt is displayed and no input is accepted, during this time > the jshell tool watches the temp file for changes, entering any > changes. When the editor exits the jshell tool stops watching. > > From my experiments with gedit, what is happening in this case is > that the first time the gedit command is used it creates the > window and waits for all windows to close before exiting. > Subsequent calls to gedit add a pane for the file and return immediately. > As a result the jshell tool assumes the editor has exited, stops > watching the file, and queries for input with a prompt. > > For gedit, this can be addressed by using the --wait or maybe > better the --standalone option: > > /set editor gedit -s > > However, other editors do not have support for waiting. > > The implemented solution: Add a "-wait" option to '/set editor' > which prompts and waits before transitioning from edit mode. > > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8158738 > > Webrev: > http://cr.openjdk.java.net/~rfield/8158738v0.webrev/ > > Thanks, > Robert > From robert.field at oracle.com Fri Aug 26 18:11:40 2016 From: robert.field at oracle.com (Robert Field) Date: Fri, 26 Aug 2016 11:11:40 -0700 Subject: RFR JDK-8131023: JShell: System.in does not work In-Reply-To: <57BF2CCB.7080406@oracle.com> References: <57BF0D77.8000901@oracle.com> <57BF2CCB.7080406@oracle.com> Message-ID: <57C0865C.1070503@oracle.com> Continued... MultiplexingOutputStream.java Was this changed so that it occurs in a single write that won't get interleaved? Do we have this issue elsewhere? The encoding is now complex enough that the special unrolling for 'void write(int b)' isn't justified. Could be just: byte[] a = { b }; write(a, 0, 1); Thumbs up if those two issues (above and below) are addressed. -Robert On 08/25/16 10:37, Robert Field wrote: > As the bug title states, System.in does not work from Snippets. In a > command line tool there is only one "in", even though the constructor > for the tool takes a separate cmdIn and userIn. So, for a command > line tool to work these need to be unified. However, though the JShell > API is the recommended approach to creating new tools, some will > choose to wrap the tool, say in a GUI. In fact this has already been > done. Such a wrapped tool can have separate input channels. Rather > than changing the constructor for JShellTool to remove the userIn > parameter, it would seem to leave more options open if a new > constructor with just one input parameter (not named "cmdIn") was > added which forwards to the old constructor. > > More later... > > > On 08/25/16 08:23, Jan Lahoda wrote: >> Hi, >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8131023 >> >> Langtools webrev: >> http://cr.openjdk.java.net/~jlahoda/8131023/langtools.00/ >> >> JDK repository webrev: >> http://cr.openjdk.java.net/~jlahoda/8131023/jdk.00/ >> >> Specdiff: >> http://cr.openjdk.java.net/~jlahoda/8131023/diff.00/jdk/jshell/execution/Util.html >> >> >> Currently jshell forwards output from the agent to the main process. >> With this patch, the input is also forwarded from the main process to >> the agent. InputStream.read() is only called in the main process if >> it has been called on the agent side; this is achieved by using an >> artificial OutputStream in the agent->main process direction. On the >> agent side, when an input is requested, a character is written to the >> corresponding artificial OutputStream, the main process is about >> that, reads from the actual input and sends the data back to the agent. >> >> In the tool, jline is used to actually read the input, as System.in >> is switched in the raw mode. This requires a tweak in jline, to >> detect the proper column on which the editing starts, to cover >> requests like: >> >> System.err.print("Prompt: "); System.err.flush(); System.in.read(); >> >> Without the tweak, the line editor wouldn't unfortunately know about >> the text written to the console (for supported terminals, at least). >> (This tweak may be useful in any case for complex prompts that use >> escape sequences; also for jjs.) >> >> An alternative would be to try to switch jline off while reading the >> user's input. The advantage of using jline is that it allows to >> detect Ctrl-C. >> >> Any feedback is welcome! >> >> Thanks, >> Jan > From robert.field at oracle.com Fri Aug 26 20:19:39 2016 From: robert.field at oracle.com (Robert Field) Date: Fri, 26 Aug 2016 13:19:39 -0700 Subject: RFR 8133507: JShell API: StackTraceElement#getFileName of EvalException does not use custom id Message-ID: <57C0A45B.2030709@oracle.com> Please review.... Bug: https://bugs.openjdk.java.net/browse/JDK-8133507 Webrev: http://cr.openjdk.java.net/~rfield/8133507v0.webrev/ Thanks, Robert From robert.field at oracle.com Fri Aug 26 21:48:43 2016 From: robert.field at oracle.com (Robert Field) Date: Fri, 26 Aug 2016 14:48:43 -0700 Subject: RFR 8158507: JShell: new jdk.jshell.MemoryFileManager(StandardJavaFileManager, JShell) creates a jdk.jshell.MemoryFileManager$REPLClassLoader classloader, which should be performed within a doPrivileged block Message-ID: <57C0B93B.9090808@oracle.com> The solution for this one is to simply remove code that was left around to support potential restoration of process-local execution support. Process-local execution is now directly supported through the SPI and using jdk.jshell.execution.LocalExecutionControl. Please review... Bug: https://bugs.openjdk.java.net/browse/JDK-8158507 Webrev: http://cr.openjdk.java.net/~rfield/8158507v0.webrev/ Thanks, Robert From bitterfoxc at gmail.com Sat Aug 27 04:46:35 2016 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Sat, 27 Aug 2016 13:46:35 +0900 Subject: RFR 8164825: jshell tool: Completion for subcommand Message-ID: Hi all, Could you review this? Bug: https://bugs.openjdk.java.net/browse/JDK-8164825 Webrev: http://cr.openjdk.java.net/~shinyafox/kulla/8164825/webrev.00/ Regards, shinyafox(Shinya Yoshida) From jan.lahoda at oracle.com Sun Aug 28 20:26:10 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Sun, 28 Aug 2016 22:26:10 +0200 Subject: RFR JDK-8131023: JShell: System.in does not work In-Reply-To: <57C0865C.1070503@oracle.com> References: <57BF0D77.8000901@oracle.com> <57BF2CCB.7080406@oracle.com> <57C0865C.1070503@oracle.com> Message-ID: <57C348E2.5000207@oracle.com> Hi, Langtools patch updated to reflect the comments is here: http://cr.openjdk.java.net/~jlahoda/8131023/langtools.01/ How does it look? Thanks, Jan On 26.8.2016 20:11, Robert Field wrote: > Continued... > > MultiplexingOutputStream.java > > Was this changed so that it occurs in a single write that won't get > interleaved? Do we have this issue elsewhere? The encoding is now > complex enough that the special unrolling for 'void write(int b)' isn't > justified. Could be just: > > byte[] a = { b }; > write(a, 0, 1); > > Thumbs up if those two issues (above and below) are addressed. > > -Robert > > On 08/25/16 10:37, Robert Field wrote: >> As the bug title states, System.in does not work from Snippets. In a >> command line tool there is only one "in", even though the constructor >> for the tool takes a separate cmdIn and userIn. So, for a command >> line tool to work these need to be unified. However, though the JShell >> API is the recommended approach to creating new tools, some will >> choose to wrap the tool, say in a GUI. In fact this has already been >> done. Such a wrapped tool can have separate input channels. Rather >> than changing the constructor for JShellTool to remove the userIn >> parameter, it would seem to leave more options open if a new >> constructor with just one input parameter (not named "cmdIn") was >> added which forwards to the old constructor. >> >> More later... >> >> >> On 08/25/16 08:23, Jan Lahoda wrote: >>> Hi, >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8131023 >>> >>> Langtools webrev: >>> http://cr.openjdk.java.net/~jlahoda/8131023/langtools.00/ >>> >>> JDK repository webrev: >>> http://cr.openjdk.java.net/~jlahoda/8131023/jdk.00/ >>> >>> Specdiff: >>> http://cr.openjdk.java.net/~jlahoda/8131023/diff.00/jdk/jshell/execution/Util.html >>> >>> >>> Currently jshell forwards output from the agent to the main process. >>> With this patch, the input is also forwarded from the main process to >>> the agent. InputStream.read() is only called in the main process if >>> it has been called on the agent side; this is achieved by using an >>> artificial OutputStream in the agent->main process direction. On the >>> agent side, when an input is requested, a character is written to the >>> corresponding artificial OutputStream, the main process is about >>> that, reads from the actual input and sends the data back to the agent. >>> >>> In the tool, jline is used to actually read the input, as System.in >>> is switched in the raw mode. This requires a tweak in jline, to >>> detect the proper column on which the editing starts, to cover >>> requests like: >>> >>> System.err.print("Prompt: "); System.err.flush(); System.in.read(); >>> >>> Without the tweak, the line editor wouldn't unfortunately know about >>> the text written to the console (for supported terminals, at least). >>> (This tweak may be useful in any case for complex prompts that use >>> escape sequences; also for jjs.) >>> >>> An alternative would be to try to switch jline off while reading the >>> user's input. The advantage of using jline is that it allows to >>> detect Ctrl-C. >>> >>> Any feedback is welcome! >>> >>> Thanks, >>> Jan >> > From jan.lahoda at oracle.com Mon Aug 29 08:52:43 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 29 Aug 2016 10:52:43 +0200 Subject: RFR 8158507: JShell: new jdk.jshell.MemoryFileManager(StandardJavaFileManager, JShell) creates a jdk.jshell.MemoryFileManager$REPLClassLoader classloader, which should be performed within a doPrivileged block In-Reply-To: <57C0B93B.9090808@oracle.com> References: <57C0B93B.9090808@oracle.com> Message-ID: <57C3F7DB.5000001@oracle.com> Seems OK to me. Jan On 26.8.2016 23:48, Robert Field wrote: > The solution for this one is to simply remove code that was left around > to support potential restoration of process-local execution support. > Process-local execution is now directly supported through the SPI and > using jdk.jshell.execution.LocalExecutionControl. > > Please review... > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8158507 > > Webrev: > http://cr.openjdk.java.net/~rfield/8158507v0.webrev/ > > Thanks, > Robert > From jan.lahoda at oracle.com Mon Aug 29 12:04:35 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 29 Aug 2016 14:04:35 +0200 Subject: RFR 8164825: jshell tool: Completion for subcommand In-Reply-To: References: Message-ID: <57C424D3.4080309@oracle.com> Hi Shinya, Seems good to me. Jan On 27.8.2016 06:46, ShinyaYoshida wrote: > Hi all, > Could you review this? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8164825 > > Webrev: http://cr.openjdk.java.net/~shinyafox/kulla/8164825/webrev.00/ > > Regards, > shinyafox(Shinya Yoshida) > From robert.field at oracle.com Mon Aug 29 15:40:28 2016 From: robert.field at oracle.com (Robert Field) Date: Mon, 29 Aug 2016 08:40:28 -0700 Subject: RFR JDK-8131023: JShell: System.in does not work In-Reply-To: <57C348E2.5000207@oracle.com> References: <57BF0D77.8000901@oracle.com> <57BF2CCB.7080406@oracle.com> <57C0865C.1070503@oracle.com> <57C348E2.5000207@oracle.com> Message-ID: <57C4576C.9030608@oracle.com> Thumbs up! -Robert On 08/28/16 13:26, Jan Lahoda wrote: > Hi, > > Langtools patch updated to reflect the comments is here: > http://cr.openjdk.java.net/~jlahoda/8131023/langtools.01/ > > How does it look? > > Thanks, > Jan > > On 26.8.2016 20:11, Robert Field wrote: >> Continued... >> >> MultiplexingOutputStream.java >> >> Was this changed so that it occurs in a single write that won't get >> interleaved? Do we have this issue elsewhere? The encoding is now >> complex enough that the special unrolling for 'void write(int b)' isn't >> justified. Could be just: >> >> byte[] a = { b }; >> write(a, 0, 1); >> >> Thumbs up if those two issues (above and below) are addressed. >> >> -Robert >> >> On 08/25/16 10:37, Robert Field wrote: >>> As the bug title states, System.in does not work from Snippets. In a >>> command line tool there is only one "in", even though the constructor >>> for the tool takes a separate cmdIn and userIn. So, for a command >>> line tool to work these need to be unified. However, though the JShell >>> API is the recommended approach to creating new tools, some will >>> choose to wrap the tool, say in a GUI. In fact this has already been >>> done. Such a wrapped tool can have separate input channels. Rather >>> than changing the constructor for JShellTool to remove the userIn >>> parameter, it would seem to leave more options open if a new >>> constructor with just one input parameter (not named "cmdIn") was >>> added which forwards to the old constructor. >>> >>> More later... >>> >>> >>> On 08/25/16 08:23, Jan Lahoda wrote: >>>> Hi, >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8131023 >>>> >>>> Langtools webrev: >>>> http://cr.openjdk.java.net/~jlahoda/8131023/langtools.00/ >>>> >>>> JDK repository webrev: >>>> http://cr.openjdk.java.net/~jlahoda/8131023/jdk.00/ >>>> >>>> Specdiff: >>>> http://cr.openjdk.java.net/~jlahoda/8131023/diff.00/jdk/jshell/execution/Util.html >>>> >>>> >>>> >>>> Currently jshell forwards output from the agent to the main process. >>>> With this patch, the input is also forwarded from the main process to >>>> the agent. InputStream.read() is only called in the main process if >>>> it has been called on the agent side; this is achieved by using an >>>> artificial OutputStream in the agent->main process direction. On the >>>> agent side, when an input is requested, a character is written to the >>>> corresponding artificial OutputStream, the main process is about >>>> that, reads from the actual input and sends the data back to the >>>> agent. >>>> >>>> In the tool, jline is used to actually read the input, as System.in >>>> is switched in the raw mode. This requires a tweak in jline, to >>>> detect the proper column on which the editing starts, to cover >>>> requests like: >>>> >>>> System.err.print("Prompt: "); System.err.flush(); System.in.read(); >>>> >>>> Without the tweak, the line editor wouldn't unfortunately know about >>>> the text written to the console (for supported terminals, at least). >>>> (This tweak may be useful in any case for complex prompts that use >>>> escape sequences; also for jjs.) >>>> >>>> An alternative would be to try to switch jline off while reading the >>>> user's input. The advantage of using jline is that it allows to >>>> detect Ctrl-C. >>>> >>>> Any feedback is welcome! >>>> >>>> Thanks, >>>> Jan >>> >> From jan.lahoda at oracle.com Tue Aug 30 16:42:40 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 30 Aug 2016 18:42:40 +0200 Subject: RFR 8133507: JShell API: StackTraceElement#getFileName of EvalException does not use custom id In-Reply-To: <57C0A45B.2030709@oracle.com> References: <57C0A45B.2030709@oracle.com> Message-ID: <57C5B780.50505@oracle.com> Seems OK to me. Jan On 26.8.2016 22:19, Robert Field wrote: > Please review.... > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8133507 > > Webrev: > http://cr.openjdk.java.net/~rfield/8133507v0.webrev/ > > Thanks, > Robert >