From volker.simonis at gmail.com Fri Jan 19 15:52:49 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 19 Jan 2018 16:52:49 +0100 Subject: CODETOOLS-7902102 jtharness crashes with StackOverflowError if called from 'jtreg -gui Message-ID: Hi, can somebody please have a look at the following issue, which prevents users who built jtreg/jtharness from source to run jtreg in gui mode. I can provide a trivial fix as sketched at the end of the problem description if that's desired? Thank you and best regards, Volker https://bugs.openjdk.java.net/browse/CODETOOLS-7902102 If you build jtreg and jtharness from source (e.g. with the new "make/buiild-all.sh" script from jtreg) and run 'jtreg -gui' jtharness will crash with the following StackOverflowError: Error: Unexpected exception occurred! java.lang.StackOverflowError java.lang.StackOverflowError at java.base/java.util.ResourceBundle$CacheKey.hashCode(ResourceBundle.java:724) at java.base/java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:946) at java.base/java.util.ResourceBundle.findBundleInCache(ResourceBundle.java:2066) at java.base/java.util.ResourceBundle.findBundle(ResourceBundle.java:1742) at java.base/java.util.ResourceBundle.findBundle(ResourceBundle.java:1720) at java.base/java.util.ResourceBundle.findBundle(ResourceBundle.java:1720) at java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1654) at java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1585) at java.base/java.util.ResourceBundle.getBundle(ResourceBundle.java:1276) at com.sun.javatest.ResourceLoader$2.run(ResourceLoader.java:217) at com.sun.javatest.ResourceLoader$2.run(ResourceLoader.java:215) at java.base/java.security.AccessController.doPrivileged(Native Method) at com.sun.javatest.ResourceLoader.getSBundle(ResourceLoader.java:214) at com.sun.javatest.ResourceLoader.getBundle(ResourceLoader.java:199) at com.sun.javatest.util.I18NResourceBundle$1.run(I18NResourceBundle.java:121) at com.sun.javatest.util.I18NResourceBundle$1.run(I18NResourceBundle.java:119) at java.base/java.security.AccessController.doPrivileged(Native Method) at com.sun.javatest.util.I18NResourceBundle.getObj(I18NResourceBundle.java:118) at com.sun.javatest.util.I18NResourceBundle.getOptionalString(I18NResourceBundle.java:104) at com.sun.javatest.tool.Startup.show(Startup.java:97) at com.sun.javatest.tool.Startup.showDefault(Startup.java:93) at com.sun.javatest.tool.Startup.show(Startup.java:105) at com.sun.javatest.tool.Startup.showDefault(Startup.java:93) at com.sun.javatest.tool.Startup.show(Startup.java:105) at com.sun.javatest.tool.Startup.showDefault(Startup.java:93) ... This is because jtharness tries to load the splash screen image from "com/sun/javatest/tool/images/splash.gif" which doesn't exist and leeds to an infinite recursion. The splash screen image is defined in com/sun/javatest/tool/i18n.properties: startup.icon=com/sun/javatest/tool/images/splash.gif but com/sun/javatest/tool/images only contains: jticon.gif jtlogo.png selected.gif spl_412.gif spl_413.gif spl_421.gif spl_42.gif spl_43.gif spl_441.gif spl_44.gif jtlogo.gif partially.gif spl_412F.gif spl_413F.gif spl_421F.gif spl_42F.gif spl_43F.gif spl_441F.gif spl_44F.gif unselected.gif but no splash.gif. The trivial fix would be to either create a generic "splash.gif" or to define startup.icon to point to an existing image. The problem is that the splash screen gifs contain a string with the jtHarness version. So a more general solution would be to create such a gif as part of the build (e.g. from a generic template). I think this a "day-zero" problem (at lease from the day the jtHarness sources are in the OpenJDK Mercurial repositories) but has never been encountered because people usually used pre-built version of jtHarness from Oracle which contain a valid "splash.gif" icon. Now, with the new jtReg build script "make/buiild-all.sh" which makes it easy for everybody to build jtReg and all its dependencies (including jtHarness) from source this problem will affect everybody who does so! From volker.simonis at gmail.com Fri Jan 19 16:46:56 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 19 Jan 2018 17:46:56 +0100 Subject: CODETOOLS-7902102 jtharness crashes with StackOverflowError if called from 'jtreg -gui In-Reply-To: References: Message-ID: Looking more closely at this issue, I think the correct "quick fix" will be to add the following copy action to the "compile.resources" target in build/build.xml Just renaming the startup.icon to an existing icon wouldn't help because the icons names "spl_*.gif" are not copied over into the generated images. Creating a generic "splash.gif" would also help, because that one will be copied over into the generated images. Regards, Volker On Fri, Jan 19, 2018 at 4:52 PM, Volker Simonis wrote: > Hi, > > can somebody please have a look at the following issue, which prevents > users who built jtreg/jtharness from source to run jtreg in gui mode. > I can provide a trivial fix as sketched at the end of the problem > description if that's desired? > > Thank you and best regards, > Volker > > https://bugs.openjdk.java.net/browse/CODETOOLS-7902102 > > If you build jtreg and jtharness from source (e.g. with the new > "make/buiild-all.sh" script from jtreg) and run 'jtreg -gui' jtharness > will crash with the following StackOverflowError: > > Error: Unexpected exception occurred! java.lang.StackOverflowError > java.lang.StackOverflowError > at java.base/java.util.ResourceBundle$CacheKey.hashCode(ResourceBundle.java:724) > at java.base/java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:946) > at java.base/java.util.ResourceBundle.findBundleInCache(ResourceBundle.java:2066) > at java.base/java.util.ResourceBundle.findBundle(ResourceBundle.java:1742) > at java.base/java.util.ResourceBundle.findBundle(ResourceBundle.java:1720) > at java.base/java.util.ResourceBundle.findBundle(ResourceBundle.java:1720) > at java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1654) > at java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1585) > at java.base/java.util.ResourceBundle.getBundle(ResourceBundle.java:1276) > at com.sun.javatest.ResourceLoader$2.run(ResourceLoader.java:217) > at com.sun.javatest.ResourceLoader$2.run(ResourceLoader.java:215) > at java.base/java.security.AccessController.doPrivileged(Native Method) > at com.sun.javatest.ResourceLoader.getSBundle(ResourceLoader.java:214) > at com.sun.javatest.ResourceLoader.getBundle(ResourceLoader.java:199) > at com.sun.javatest.util.I18NResourceBundle$1.run(I18NResourceBundle.java:121) > at com.sun.javatest.util.I18NResourceBundle$1.run(I18NResourceBundle.java:119) > at java.base/java.security.AccessController.doPrivileged(Native Method) > at com.sun.javatest.util.I18NResourceBundle.getObj(I18NResourceBundle.java:118) > at com.sun.javatest.util.I18NResourceBundle.getOptionalString(I18NResourceBundle.java:104) > at com.sun.javatest.tool.Startup.show(Startup.java:97) > at com.sun.javatest.tool.Startup.showDefault(Startup.java:93) > at com.sun.javatest.tool.Startup.show(Startup.java:105) > at com.sun.javatest.tool.Startup.showDefault(Startup.java:93) > at com.sun.javatest.tool.Startup.show(Startup.java:105) > at com.sun.javatest.tool.Startup.showDefault(Startup.java:93) > ... > > This is because jtharness tries to load the splash screen image from > "com/sun/javatest/tool/images/splash.gif" which doesn't exist and > leeds to an infinite recursion. > > The splash screen image is defined in com/sun/javatest/tool/i18n.properties: > > startup.icon=com/sun/javatest/tool/images/splash.gif > > but com/sun/javatest/tool/images only contains: > > jticon.gif jtlogo.png selected.gif spl_412.gif spl_413.gif spl_421.gif > spl_42.gif spl_43.gif spl_441.gif spl_44.gif > jtlogo.gif partially.gif spl_412F.gif spl_413F.gif spl_421F.gif > spl_42F.gif spl_43F.gif spl_441F.gif spl_44F.gif unselected.gif > > but no splash.gif. > > The trivial fix would be to either create a generic "splash.gif" or to > define startup.icon to point to an existing image. > > The problem is that the splash screen gifs contain a string with the > jtHarness version. So a more general solution would be to create such > a gif as part of the build (e.g. from a generic template). > > I think this a "day-zero" problem (at lease from the day the jtHarness > sources are in the OpenJDK Mercurial repositories) but has never been > encountered because people usually used pre-built version of jtHarness > from Oracle which contain a valid "splash.gif" icon. > > Now, with the new jtReg build script "make/buiild-all.sh" which makes > it easy for everybody to build jtReg and all its dependencies > (including jtHarness) from source this problem will affect everybody > who does so! From alexey.fedorchenko at oracle.com Tue Jan 23 13:56:49 2018 From: alexey.fedorchenko at oracle.com (Alexey Fedorchenko) Date: Tue, 23 Jan 2018 16:56:49 +0300 Subject: CODETOOLS-7902102 jtharness crashes with StackOverflowError if called from 'jtreg -gui In-Reply-To: References: Message-ID: <57A9A4C9-0235-4FB6-9176-AABEFFA515C2@oracle.com> Hello! Thank you for the report. The first patch was added to JTHarness repo (the current approach should be changed for 508 compliance). Now it should be possible to use JTReg build-all script to build JTReg and run it in gui mode. You need to change JTHarness mercurial tag in the build-all script (JTHARNESS_VERSION=fdf62f8d752f) to try it. Thank you. ?Alexey > On Jan 19, 2018, at 7:46 PM, Volker Simonis wrote: > > Looking more closely at this issue, I think the correct "quick fix" > will be to add the following copy action to the "compile.resources" > target in build/build.xml > > tofile="${build.classes}/com/sun/javatest/tool/images/splash.gif"/> > > Just renaming the startup.icon to an existing icon wouldn't help > because the icons names "spl_*.gif" are not copied over into the > generated images. > > Creating a generic "splash.gif" would also help, because that one will > be copied over into the generated images. > > Regards, > Volker > > > On Fri, Jan 19, 2018 at 4:52 PM, Volker Simonis > wrote: >> Hi, >> >> can somebody please have a look at the following issue, which prevents >> users who built jtreg/jtharness from source to run jtreg in gui mode. >> I can provide a trivial fix as sketched at the end of the problem >> description if that's desired? >> >> Thank you and best regards, >> Volker >> >> https://bugs.openjdk.java.net/browse/CODETOOLS-7902102 >> >> If you build jtreg and jtharness from source (e.g. with the new >> "make/buiild-all.sh" script from jtreg) and run 'jtreg -gui' jtharness >> will crash with the following StackOverflowError: >> >> Error: Unexpected exception occurred! java.lang.StackOverflowError >> java.lang.StackOverflowError >> at java.base/java.util.ResourceBundle$CacheKey.hashCode(ResourceBundle.java:724) >> at java.base/java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:946) >> at java.base/java.util.ResourceBundle.findBundleInCache(ResourceBundle.java:2066) >> at java.base/java.util.ResourceBundle.findBundle(ResourceBundle.java:1742) >> at java.base/java.util.ResourceBundle.findBundle(ResourceBundle.java:1720) >> at java.base/java.util.ResourceBundle.findBundle(ResourceBundle.java:1720) >> at java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1654) >> at java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1585) >> at java.base/java.util.ResourceBundle.getBundle(ResourceBundle.java:1276) >> at com.sun.javatest.ResourceLoader$2.run(ResourceLoader.java:217) >> at com.sun.javatest.ResourceLoader$2.run(ResourceLoader.java:215) >> at java.base/java.security.AccessController.doPrivileged(Native Method) >> at com.sun.javatest.ResourceLoader.getSBundle(ResourceLoader.java:214) >> at com.sun.javatest.ResourceLoader.getBundle(ResourceLoader.java:199) >> at com.sun.javatest.util.I18NResourceBundle$1.run(I18NResourceBundle.java:121) >> at com.sun.javatest.util.I18NResourceBundle$1.run(I18NResourceBundle.java:119) >> at java.base/java.security.AccessController.doPrivileged(Native Method) >> at com.sun.javatest.util.I18NResourceBundle.getObj(I18NResourceBundle.java:118) >> at com.sun.javatest.util.I18NResourceBundle.getOptionalString(I18NResourceBundle.java:104) >> at com.sun.javatest.tool.Startup.show(Startup.java:97) >> at com.sun.javatest.tool.Startup.showDefault(Startup.java:93) >> at com.sun.javatest.tool.Startup.show(Startup.java:105) >> at com.sun.javatest.tool.Startup.showDefault(Startup.java:93) >> at com.sun.javatest.tool.Startup.show(Startup.java:105) >> at com.sun.javatest.tool.Startup.showDefault(Startup.java:93) >> ... >> >> This is because jtharness tries to load the splash screen image from >> "com/sun/javatest/tool/images/splash.gif" which doesn't exist and >> leeds to an infinite recursion. >> >> The splash screen image is defined in com/sun/javatest/tool/i18n.properties: >> >> startup.icon=com/sun/javatest/tool/images/splash.gif >> >> but com/sun/javatest/tool/images only contains: >> >> jticon.gif jtlogo.png selected.gif spl_412.gif spl_413.gif spl_421.gif >> spl_42.gif spl_43.gif spl_441.gif spl_44.gif >> jtlogo.gif partially.gif spl_412F.gif spl_413F.gif spl_421F.gif >> spl_42F.gif spl_43F.gif spl_441F.gif spl_44F.gif unselected.gif >> >> but no splash.gif. >> >> The trivial fix would be to either create a generic "splash.gif" or to >> define startup.icon to point to an existing image. >> >> The problem is that the splash screen gifs contain a string with the >> jtHarness version. So a more general solution would be to create such >> a gif as part of the build (e.g. from a generic template). >> >> I think this a "day-zero" problem (at lease from the day the jtHarness >> sources are in the OpenJDK Mercurial repositories) but has never been >> encountered because people usually used pre-built version of jtHarness >> from Oracle which contain a valid "splash.gif" icon. >> >> Now, with the new jtReg build script "make/buiild-all.sh" which makes >> it easy for everybody to build jtReg and all its dependencies >> (including jtHarness) from source this problem will affect everybody >> who does so! From volker.simonis at gmail.com Tue Jan 23 14:15:59 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 23 Jan 2018 15:15:59 +0100 Subject: CODETOOLS-7902102 jtharness crashes with StackOverflowError if called from 'jtreg -gui In-Reply-To: <57A9A4C9-0235-4FB6-9176-AABEFFA515C2@oracle.com> References: <57A9A4C9-0235-4FB6-9176-AABEFFA515C2@oracle.com> Message-ID: Hi Alexey, your change looks fine. Thanks for fixing! On Tue, Jan 23, 2018 at 2:56 PM, Alexey Fedorchenko wrote: > Hello! > > Thank you for the report. > > The first patch was added to JTHarness repo (the current approach should be changed for 508 compliance). What is "508 compliance"? > Now it should be possible to use JTReg build-all script to build JTReg and run it in gui mode. > > You need to change JTHarness mercurial tag in the build-all script (JTHARNESS_VERSION=fdf62f8d752f) to try it. > Who will be updating the build-all script ? Will you tag a new version in JTHarness for this or will it be OK to use a change ID in build-all.sh ? Finally, shouldn't you change the state of CODETOOLS-7902102 to closed in JBS now that you've committed a fix? I'm actually surprised that this doesn't happen automatically like in the JDK project. Regards, Volker PS: Will you also have the chance to look at the other bug I've opened :) CODETOOLS-7902103: Can't display test files if running with 'jtreg -gui' https://bugs.openjdk.java.net/browse/CODETOOLS-7902103 > Thank you. > > ?Alexey > >> On Jan 19, 2018, at 7:46 PM, Volker Simonis wrote: >> >> Looking more closely at this issue, I think the correct "quick fix" >> will be to add the following copy action to the "compile.resources" >> target in build/build.xml >> >> > tofile="${build.classes}/com/sun/javatest/tool/images/splash.gif"/> >> >> Just renaming the startup.icon to an existing icon wouldn't help >> because the icons names "spl_*.gif" are not copied over into the >> generated images. >> >> Creating a generic "splash.gif" would also help, because that one will >> be copied over into the generated images. >> >> Regards, >> Volker >> >> >> On Fri, Jan 19, 2018 at 4:52 PM, Volker Simonis >> wrote: >>> Hi, >>> >>> can somebody please have a look at the following issue, which prevents >>> users who built jtreg/jtharness from source to run jtreg in gui mode. >>> I can provide a trivial fix as sketched at the end of the problem >>> description if that's desired? >>> >>> Thank you and best regards, >>> Volker >>> >>> https://bugs.openjdk.java.net/browse/CODETOOLS-7902102 >>> >>> If you build jtreg and jtharness from source (e.g. with the new >>> "make/buiild-all.sh" script from jtreg) and run 'jtreg -gui' jtharness >>> will crash with the following StackOverflowError: >>> >>> Error: Unexpected exception occurred! java.lang.StackOverflowError >>> java.lang.StackOverflowError >>> at java.base/java.util.ResourceBundle$CacheKey.hashCode(ResourceBundle.java:724) >>> at java.base/java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:946) >>> at java.base/java.util.ResourceBundle.findBundleInCache(ResourceBundle.java:2066) >>> at java.base/java.util.ResourceBundle.findBundle(ResourceBundle.java:1742) >>> at java.base/java.util.ResourceBundle.findBundle(ResourceBundle.java:1720) >>> at java.base/java.util.ResourceBundle.findBundle(ResourceBundle.java:1720) >>> at java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1654) >>> at java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1585) >>> at java.base/java.util.ResourceBundle.getBundle(ResourceBundle.java:1276) >>> at com.sun.javatest.ResourceLoader$2.run(ResourceLoader.java:217) >>> at com.sun.javatest.ResourceLoader$2.run(ResourceLoader.java:215) >>> at java.base/java.security.AccessController.doPrivileged(Native Method) >>> at com.sun.javatest.ResourceLoader.getSBundle(ResourceLoader.java:214) >>> at com.sun.javatest.ResourceLoader.getBundle(ResourceLoader.java:199) >>> at com.sun.javatest.util.I18NResourceBundle$1.run(I18NResourceBundle.java:121) >>> at com.sun.javatest.util.I18NResourceBundle$1.run(I18NResourceBundle.java:119) >>> at java.base/java.security.AccessController.doPrivileged(Native Method) >>> at com.sun.javatest.util.I18NResourceBundle.getObj(I18NResourceBundle.java:118) >>> at com.sun.javatest.util.I18NResourceBundle.getOptionalString(I18NResourceBundle.java:104) >>> at com.sun.javatest.tool.Startup.show(Startup.java:97) >>> at com.sun.javatest.tool.Startup.showDefault(Startup.java:93) >>> at com.sun.javatest.tool.Startup.show(Startup.java:105) >>> at com.sun.javatest.tool.Startup.showDefault(Startup.java:93) >>> at com.sun.javatest.tool.Startup.show(Startup.java:105) >>> at com.sun.javatest.tool.Startup.showDefault(Startup.java:93) >>> ... >>> >>> This is because jtharness tries to load the splash screen image from >>> "com/sun/javatest/tool/images/splash.gif" which doesn't exist and >>> leeds to an infinite recursion. >>> >>> The splash screen image is defined in com/sun/javatest/tool/i18n.properties: >>> >>> startup.icon=com/sun/javatest/tool/images/splash.gif >>> >>> but com/sun/javatest/tool/images only contains: >>> >>> jticon.gif jtlogo.png selected.gif spl_412.gif spl_413.gif spl_421.gif >>> spl_42.gif spl_43.gif spl_441.gif spl_44.gif >>> jtlogo.gif partially.gif spl_412F.gif spl_413F.gif spl_421F.gif >>> spl_42F.gif spl_43F.gif spl_441F.gif spl_44F.gif unselected.gif >>> >>> but no splash.gif. >>> >>> The trivial fix would be to either create a generic "splash.gif" or to >>> define startup.icon to point to an existing image. >>> >>> The problem is that the splash screen gifs contain a string with the >>> jtHarness version. So a more general solution would be to create such >>> a gif as part of the build (e.g. from a generic template). >>> >>> I think this a "day-zero" problem (at lease from the day the jtHarness >>> sources are in the OpenJDK Mercurial repositories) but has never been >>> encountered because people usually used pre-built version of jtHarness >>> from Oracle which contain a valid "splash.gif" icon. >>> >>> Now, with the new jtReg build script "make/buiild-all.sh" which makes >>> it easy for everybody to build jtReg and all its dependencies >>> (including jtHarness) from source this problem will affect everybody >>> who does so! > From jonathan.gibbons at oracle.com Tue Jan 23 15:50:42 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 23 Jan 2018 07:50:42 -0800 Subject: CODETOOLS-7902102 jtharness crashes with StackOverflowError if called from 'jtreg -gui In-Reply-To: References: <57A9A4C9-0235-4FB6-9176-AABEFFA515C2@oracle.com> Message-ID: On 1/23/18 6:15 AM, Volker Simonis wrote: > Hi Alexey, > > your change looks fine. Thanks for fixing! > > On Tue, Jan 23, 2018 at 2:56 PM, Alexey Fedorchenko > wrote: >> Hello! >> >> Thank you for the report. >> >> The first patch was added to JTHarness repo (the current approach should be changed for 508 compliance). > What is "508 compliance"? "Section 508" refers to US regulations on accessibility. >> Now it should be possible to use JTReg build-all script to build JTReg and run it in gui mode. >> >> You need to change JTHarness mercurial tag in the build-all script (JTHARNESS_VERSION=fdf62f8d752f) to try it. >> > Who will be updating the build-all script ? Will you tag a new version > in JTHarness for this or will it be OK to use a change ID in > build-all.sh ? I would prefer that we don't update build-all.sh for every single bug fix in dependencies. In general, the standard build-all.sh script should refer to tested, tagged builds, although it is technically OK to update it temporarily to refer to change IDs. > > Finally, shouldn't you change the state of CODETOOLS-7902102 to closed > in JBS now that you've committed a fix? I'm actually surprised that > this doesn't happen automatically like in the JDK project. HG Updater only knows about JDK issues and JDK repos.? We have to track other bugs manually. > > Regards, > Volker > > PS: Will you also have the chance to look at the other bug I've opened :) > > CODETOOLS-7902103: Can't display test files if running with 'jtreg -gui' > https://bugs.openjdk.java.net/browse/CODETOOLS-7902103 This is on my list. -- Jon > >> Thank you. >> >> ?Alexey >> >>> On Jan 19, 2018, at 7:46 PM, Volker Simonis wrote: >>> >>> Looking more closely at this issue, I think the correct "quick fix" >>> will be to add the following copy action to the "compile.resources" >>> target in build/build.xml >>> >>> >> tofile="${build.classes}/com/sun/javatest/tool/images/splash.gif"/> >>> >>> Just renaming the startup.icon to an existing icon wouldn't help >>> because the icons names "spl_*.gif" are not copied over into the >>> generated images. >>> >>> Creating a generic "splash.gif" would also help, because that one will >>> be copied over into the generated images. >>> >>> Regards, >>> Volker >>> >>> >>> On Fri, Jan 19, 2018 at 4:52 PM, Volker Simonis >>> wrote: >>>> Hi, >>>> >>>> can somebody please have a look at the following issue, which prevents >>>> users who built jtreg/jtharness from source to run jtreg in gui mode. >>>> I can provide a trivial fix as sketched at the end of the problem >>>> description if that's desired? >>>> >>>> Thank you and best regards, >>>> Volker >>>> >>>> https://bugs.openjdk.java.net/browse/CODETOOLS-7902102 >>>> >>>> If you build jtreg and jtharness from source (e.g. with the new >>>> "make/buiild-all.sh" script from jtreg) and run 'jtreg -gui' jtharness >>>> will crash with the following StackOverflowError: >>>> >>>> Error: Unexpected exception occurred! java.lang.StackOverflowError >>>> java.lang.StackOverflowError >>>> at java.base/java.util.ResourceBundle$CacheKey.hashCode(ResourceBundle.java:724) >>>> at java.base/java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:946) >>>> at java.base/java.util.ResourceBundle.findBundleInCache(ResourceBundle.java:2066) >>>> at java.base/java.util.ResourceBundle.findBundle(ResourceBundle.java:1742) >>>> at java.base/java.util.ResourceBundle.findBundle(ResourceBundle.java:1720) >>>> at java.base/java.util.ResourceBundle.findBundle(ResourceBundle.java:1720) >>>> at java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1654) >>>> at java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1585) >>>> at java.base/java.util.ResourceBundle.getBundle(ResourceBundle.java:1276) >>>> at com.sun.javatest.ResourceLoader$2.run(ResourceLoader.java:217) >>>> at com.sun.javatest.ResourceLoader$2.run(ResourceLoader.java:215) >>>> at java.base/java.security.AccessController.doPrivileged(Native Method) >>>> at com.sun.javatest.ResourceLoader.getSBundle(ResourceLoader.java:214) >>>> at com.sun.javatest.ResourceLoader.getBundle(ResourceLoader.java:199) >>>> at com.sun.javatest.util.I18NResourceBundle$1.run(I18NResourceBundle.java:121) >>>> at com.sun.javatest.util.I18NResourceBundle$1.run(I18NResourceBundle.java:119) >>>> at java.base/java.security.AccessController.doPrivileged(Native Method) >>>> at com.sun.javatest.util.I18NResourceBundle.getObj(I18NResourceBundle.java:118) >>>> at com.sun.javatest.util.I18NResourceBundle.getOptionalString(I18NResourceBundle.java:104) >>>> at com.sun.javatest.tool.Startup.show(Startup.java:97) >>>> at com.sun.javatest.tool.Startup.showDefault(Startup.java:93) >>>> at com.sun.javatest.tool.Startup.show(Startup.java:105) >>>> at com.sun.javatest.tool.Startup.showDefault(Startup.java:93) >>>> at com.sun.javatest.tool.Startup.show(Startup.java:105) >>>> at com.sun.javatest.tool.Startup.showDefault(Startup.java:93) >>>> ... >>>> >>>> This is because jtharness tries to load the splash screen image from >>>> "com/sun/javatest/tool/images/splash.gif" which doesn't exist and >>>> leeds to an infinite recursion. >>>> >>>> The splash screen image is defined in com/sun/javatest/tool/i18n.properties: >>>> >>>> startup.icon=com/sun/javatest/tool/images/splash.gif >>>> >>>> but com/sun/javatest/tool/images only contains: >>>> >>>> jticon.gif jtlogo.png selected.gif spl_412.gif spl_413.gif spl_421.gif >>>> spl_42.gif spl_43.gif spl_441.gif spl_44.gif >>>> jtlogo.gif partially.gif spl_412F.gif spl_413F.gif spl_421F.gif >>>> spl_42F.gif spl_43F.gif spl_441F.gif spl_44F.gif unselected.gif >>>> >>>> but no splash.gif. >>>> >>>> The trivial fix would be to either create a generic "splash.gif" or to >>>> define startup.icon to point to an existing image. >>>> >>>> The problem is that the splash screen gifs contain a string with the >>>> jtHarness version. So a more general solution would be to create such >>>> a gif as part of the build (e.g. from a generic template). >>>> >>>> I think this a "day-zero" problem (at lease from the day the jtHarness >>>> sources are in the OpenJDK Mercurial repositories) but has never been >>>> encountered because people usually used pre-built version of jtHarness >>>> from Oracle which contain a valid "splash.gif" icon. >>>> >>>> Now, with the new jtReg build script "make/buiild-all.sh" which makes >>>> it easy for everybody to build jtReg and all its dependencies >>>> (including jtHarness) from source this problem will affect everybody >>>> who does so! From volker.simonis at gmail.com Tue Jan 23 16:21:34 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 23 Jan 2018 17:21:34 +0100 Subject: CODETOOLS-7902102 jtharness crashes with StackOverflowError if called from 'jtreg -gui In-Reply-To: References: <57A9A4C9-0235-4FB6-9176-AABEFFA515C2@oracle.com> Message-ID: On Tue, Jan 23, 2018 at 4:50 PM, Jonathan Gibbons wrote: > > > On 1/23/18 6:15 AM, Volker Simonis wrote: >> >> Hi Alexey, >> >> your change looks fine. Thanks for fixing! >> >> On Tue, Jan 23, 2018 at 2:56 PM, Alexey Fedorchenko >> wrote: >>> >>> Hello! >>> >>> Thank you for the report. >>> >>> The first patch was added to JTHarness repo (the current approach >>> should be changed for 508 compliance). >> >> What is "508 compliance"? > > "Section 508" refers to US regulations on accessibility. I see - that's heavy stuff :) Thanks for the explanation. > >>> Now it should be possible to use JTReg build-all script to build JTReg >>> and run it in gui mode. >>> >>> You need to change JTHarness mercurial tag in the build-all script >>> (JTHARNESS_VERSION=fdf62f8d752f) to try it. >>> >> Who will be updating the build-all script ? Will you tag a new version >> in JTHarness for this or will it be OK to use a change ID in >> build-all.sh ? > > I would prefer that we don't update build-all.sh for every single bug fix in > dependencies. > In general, the standard build-all.sh script should refer to tested, tagged > builds, although > it is technically OK to update it temporarily to refer to change IDs. > I agree, but in this case it is a pretty major loss in functionality. At least in my opinion, although obviously nobody else has noticed it until now. We can wait until somebody else complains that "jterg -gui" doesn't work. >> >> Finally, shouldn't you change the state of CODETOOLS-7902102 to closed >> in JBS now that you've committed a fix? I'm actually surprised that >> this doesn't happen automatically like in the JDK project. > > HG Updater only knows about JDK issues and JDK repos. We have to track > other bugs manually. > >> >> Regards, >> Volker >> >> PS: Will you also have the chance to look at the other bug I've opened :) >> >> CODETOOLS-7902103: Can't display test files if running with 'jtreg -gui' >> https://bugs.openjdk.java.net/browse/CODETOOLS-7902103 > > This is on my list. > That's great - thanks! Volker > -- Jon > >> >>> Thank you. >>> >>> ?Alexey >>> >>>> On Jan 19, 2018, at 7:46 PM, Volker Simonis >>>> wrote: >>>> >>>> Looking more closely at this issue, I think the correct "quick fix" >>>> will be to add the following copy action to the "compile.resources" >>>> target in build/build.xml >>>> >>>> >>> >>>> tofile="${build.classes}/com/sun/javatest/tool/images/splash.gif"/> >>>> >>>> Just renaming the startup.icon to an existing icon wouldn't help >>>> because the icons names "spl_*.gif" are not copied over into the >>>> generated images. >>>> >>>> Creating a generic "splash.gif" would also help, because that one will >>>> be copied over into the generated images. >>>> >>>> Regards, >>>> Volker >>>> >>>> >>>> On Fri, Jan 19, 2018 at 4:52 PM, Volker Simonis >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> can somebody please have a look at the following issue, which prevents >>>>> users who built jtreg/jtharness from source to run jtreg in gui mode. >>>>> I can provide a trivial fix as sketched at the end of the problem >>>>> description if that's desired? >>>>> >>>>> Thank you and best regards, >>>>> Volker >>>>> >>>>> https://bugs.openjdk.java.net/browse/CODETOOLS-7902102 >>>>> >>>>> If you build jtreg and jtharness from source (e.g. with the new >>>>> "make/buiild-all.sh" script from jtreg) and run 'jtreg -gui' jtharness >>>>> will crash with the following StackOverflowError: >>>>> >>>>> Error: Unexpected exception occurred! java.lang.StackOverflowError >>>>> java.lang.StackOverflowError >>>>> at >>>>> java.base/java.util.ResourceBundle$CacheKey.hashCode(ResourceBundle.java:724) >>>>> at >>>>> java.base/java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:946) >>>>> at >>>>> java.base/java.util.ResourceBundle.findBundleInCache(ResourceBundle.java:2066) >>>>> at >>>>> java.base/java.util.ResourceBundle.findBundle(ResourceBundle.java:1742) >>>>> at >>>>> java.base/java.util.ResourceBundle.findBundle(ResourceBundle.java:1720) >>>>> at >>>>> java.base/java.util.ResourceBundle.findBundle(ResourceBundle.java:1720) >>>>> at >>>>> java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1654) >>>>> at >>>>> java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1585) >>>>> at >>>>> java.base/java.util.ResourceBundle.getBundle(ResourceBundle.java:1276) >>>>> at com.sun.javatest.ResourceLoader$2.run(ResourceLoader.java:217) >>>>> at com.sun.javatest.ResourceLoader$2.run(ResourceLoader.java:215) >>>>> at java.base/java.security.AccessController.doPrivileged(Native Method) >>>>> at com.sun.javatest.ResourceLoader.getSBundle(ResourceLoader.java:214) >>>>> at com.sun.javatest.ResourceLoader.getBundle(ResourceLoader.java:199) >>>>> at >>>>> com.sun.javatest.util.I18NResourceBundle$1.run(I18NResourceBundle.java:121) >>>>> at >>>>> com.sun.javatest.util.I18NResourceBundle$1.run(I18NResourceBundle.java:119) >>>>> at java.base/java.security.AccessController.doPrivileged(Native Method) >>>>> at >>>>> com.sun.javatest.util.I18NResourceBundle.getObj(I18NResourceBundle.java:118) >>>>> at >>>>> com.sun.javatest.util.I18NResourceBundle.getOptionalString(I18NResourceBundle.java:104) >>>>> at com.sun.javatest.tool.Startup.show(Startup.java:97) >>>>> at com.sun.javatest.tool.Startup.showDefault(Startup.java:93) >>>>> at com.sun.javatest.tool.Startup.show(Startup.java:105) >>>>> at com.sun.javatest.tool.Startup.showDefault(Startup.java:93) >>>>> at com.sun.javatest.tool.Startup.show(Startup.java:105) >>>>> at com.sun.javatest.tool.Startup.showDefault(Startup.java:93) >>>>> ... >>>>> >>>>> This is because jtharness tries to load the splash screen image from >>>>> "com/sun/javatest/tool/images/splash.gif" which doesn't exist and >>>>> leeds to an infinite recursion. >>>>> >>>>> The splash screen image is defined in >>>>> com/sun/javatest/tool/i18n.properties: >>>>> >>>>> startup.icon=com/sun/javatest/tool/images/splash.gif >>>>> >>>>> but com/sun/javatest/tool/images only contains: >>>>> >>>>> jticon.gif jtlogo.png selected.gif spl_412.gif spl_413.gif spl_421.gif >>>>> spl_42.gif spl_43.gif spl_441.gif spl_44.gif >>>>> jtlogo.gif partially.gif spl_412F.gif spl_413F.gif spl_421F.gif >>>>> spl_42F.gif spl_43F.gif spl_441F.gif spl_44F.gif unselected.gif >>>>> >>>>> but no splash.gif. >>>>> >>>>> The trivial fix would be to either create a generic "splash.gif" or to >>>>> define startup.icon to point to an existing image. >>>>> >>>>> The problem is that the splash screen gifs contain a string with the >>>>> jtHarness version. So a more general solution would be to create such >>>>> a gif as part of the build (e.g. from a generic template). >>>>> >>>>> I think this a "day-zero" problem (at lease from the day the jtHarness >>>>> sources are in the OpenJDK Mercurial repositories) but has never been >>>>> encountered because people usually used pre-built version of jtHarness >>>>> from Oracle which contain a valid "splash.gif" icon. >>>>> >>>>> Now, with the new jtReg build script "make/buiild-all.sh" which makes >>>>> it easy for everybody to build jtReg and all its dependencies >>>>> (including jtHarness) from source this problem will affect everybody >>>>> who does so! > > From jonathan.gibbons at oracle.com Tue Jan 23 17:32:51 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 23 Jan 2018 09:32:51 -0800 Subject: CODETOOLS-7902102 jtharness crashes with StackOverflowError if called from 'jtreg -gui In-Reply-To: References: <57A9A4C9-0235-4FB6-9176-AABEFFA515C2@oracle.com> Message-ID: <3e1e06ab-8f41-ce4f-4a5e-8b1ebf5ff1a2@oracle.com> Volker, I think we should address these combined issues under the general heading of "make jtreg -gui work" and make that a focus upcoming jtreg work. -- Jon On 1/23/18 8:21 AM, Volker Simonis wrote: > On Tue, Jan 23, 2018 at 4:50 PM, Jonathan Gibbons > wrote: >> >> On 1/23/18 6:15 AM, Volker Simonis wrote: >>> Hi Alexey, >>> >>> your change looks fine. Thanks for fixing! >>> >>> On Tue, Jan 23, 2018 at 2:56 PM, Alexey Fedorchenko >>> wrote: >>>> Hello! >>>> >>>> Thank you for the report. >>>> >>>> The first patch was added to JTHarness repo (the current approach >>>> should be changed for 508 compliance). >>> What is "508 compliance"? >> "Section 508" refers to US regulations on accessibility. > I see - that's heavy stuff :) Thanks for the explanation. > >>>> Now it should be possible to use JTReg build-all script to build JTReg >>>> and run it in gui mode. >>>> >>>> You need to change JTHarness mercurial tag in the build-all script >>>> (JTHARNESS_VERSION=fdf62f8d752f) to try it. >>>> >>> Who will be updating the build-all script ? Will you tag a new version >>> in JTHarness for this or will it be OK to use a change ID in >>> build-all.sh ? >> I would prefer that we don't update build-all.sh for every single bug fix in >> dependencies. >> In general, the standard build-all.sh script should refer to tested, tagged >> builds, although >> it is technically OK to update it temporarily to refer to change IDs. >> > I agree, but in this case it is a pretty major loss in functionality. > At least in my opinion, although obviously nobody else has noticed it > until now. We can wait until somebody else complains that "jterg -gui" > doesn't work. > >>> Finally, shouldn't you change the state of CODETOOLS-7902102 to closed >>> in JBS now that you've committed a fix? I'm actually surprised that >>> this doesn't happen automatically like in the JDK project. >> HG Updater only knows about JDK issues and JDK repos. We have to track >> other bugs manually. >> >>> Regards, >>> Volker >>> >>> PS: Will you also have the chance to look at the other bug I've opened :) >>> >>> CODETOOLS-7902103: Can't display test files if running with 'jtreg -gui' >>> https://bugs.openjdk.java.net/browse/CODETOOLS-7902103 >> This is on my list. >> > That's great - thanks! > > Volker > >> -- Jon >> >>>> Thank you. >>>> >>>> ?Alexey >>>> >>>>> On Jan 19, 2018, at 7:46 PM, Volker Simonis >>>>> wrote: >>>>> >>>>> Looking more closely at this issue, I think the correct "quick fix" >>>>> will be to add the following copy action to the "compile.resources" >>>>> target in build/build.xml >>>>> >>>>> >>>> >>>>> tofile="${build.classes}/com/sun/javatest/tool/images/splash.gif"/> >>>>> >>>>> Just renaming the startup.icon to an existing icon wouldn't help >>>>> because the icons names "spl_*.gif" are not copied over into the >>>>> generated images. >>>>> >>>>> Creating a generic "splash.gif" would also help, because that one will >>>>> be copied over into the generated images. >>>>> >>>>> Regards, >>>>> Volker >>>>> >>>>> >>>>> On Fri, Jan 19, 2018 at 4:52 PM, Volker Simonis >>>>> wrote: >>>>>> Hi, >>>>>> >>>>>> can somebody please have a look at the following issue, which prevents >>>>>> users who built jtreg/jtharness from source to run jtreg in gui mode. >>>>>> I can provide a trivial fix as sketched at the end of the problem >>>>>> description if that's desired? >>>>>> >>>>>> Thank you and best regards, >>>>>> Volker >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/CODETOOLS-7902102 >>>>>> >>>>>> If you build jtreg and jtharness from source (e.g. with the new >>>>>> "make/buiild-all.sh" script from jtreg) and run 'jtreg -gui' jtharness >>>>>> will crash with the following StackOverflowError: >>>>>> >>>>>> Error: Unexpected exception occurred! java.lang.StackOverflowError >>>>>> java.lang.StackOverflowError >>>>>> at >>>>>> java.base/java.util.ResourceBundle$CacheKey.hashCode(ResourceBundle.java:724) >>>>>> at >>>>>> java.base/java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:946) >>>>>> at >>>>>> java.base/java.util.ResourceBundle.findBundleInCache(ResourceBundle.java:2066) >>>>>> at >>>>>> java.base/java.util.ResourceBundle.findBundle(ResourceBundle.java:1742) >>>>>> at >>>>>> java.base/java.util.ResourceBundle.findBundle(ResourceBundle.java:1720) >>>>>> at >>>>>> java.base/java.util.ResourceBundle.findBundle(ResourceBundle.java:1720) >>>>>> at >>>>>> java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1654) >>>>>> at >>>>>> java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1585) >>>>>> at >>>>>> java.base/java.util.ResourceBundle.getBundle(ResourceBundle.java:1276) >>>>>> at com.sun.javatest.ResourceLoader$2.run(ResourceLoader.java:217) >>>>>> at com.sun.javatest.ResourceLoader$2.run(ResourceLoader.java:215) >>>>>> at java.base/java.security.AccessController.doPrivileged(Native Method) >>>>>> at com.sun.javatest.ResourceLoader.getSBundle(ResourceLoader.java:214) >>>>>> at com.sun.javatest.ResourceLoader.getBundle(ResourceLoader.java:199) >>>>>> at >>>>>> com.sun.javatest.util.I18NResourceBundle$1.run(I18NResourceBundle.java:121) >>>>>> at >>>>>> com.sun.javatest.util.I18NResourceBundle$1.run(I18NResourceBundle.java:119) >>>>>> at java.base/java.security.AccessController.doPrivileged(Native Method) >>>>>> at >>>>>> com.sun.javatest.util.I18NResourceBundle.getObj(I18NResourceBundle.java:118) >>>>>> at >>>>>> com.sun.javatest.util.I18NResourceBundle.getOptionalString(I18NResourceBundle.java:104) >>>>>> at com.sun.javatest.tool.Startup.show(Startup.java:97) >>>>>> at com.sun.javatest.tool.Startup.showDefault(Startup.java:93) >>>>>> at com.sun.javatest.tool.Startup.show(Startup.java:105) >>>>>> at com.sun.javatest.tool.Startup.showDefault(Startup.java:93) >>>>>> at com.sun.javatest.tool.Startup.show(Startup.java:105) >>>>>> at com.sun.javatest.tool.Startup.showDefault(Startup.java:93) >>>>>> ... >>>>>> >>>>>> This is because jtharness tries to load the splash screen image from >>>>>> "com/sun/javatest/tool/images/splash.gif" which doesn't exist and >>>>>> leeds to an infinite recursion. >>>>>> >>>>>> The splash screen image is defined in >>>>>> com/sun/javatest/tool/i18n.properties: >>>>>> >>>>>> startup.icon=com/sun/javatest/tool/images/splash.gif >>>>>> >>>>>> but com/sun/javatest/tool/images only contains: >>>>>> >>>>>> jticon.gif jtlogo.png selected.gif spl_412.gif spl_413.gif spl_421.gif >>>>>> spl_42.gif spl_43.gif spl_441.gif spl_44.gif >>>>>> jtlogo.gif partially.gif spl_412F.gif spl_413F.gif spl_421F.gif >>>>>> spl_42F.gif spl_43F.gif spl_441F.gif spl_44F.gif unselected.gif >>>>>> >>>>>> but no splash.gif. >>>>>> >>>>>> The trivial fix would be to either create a generic "splash.gif" or to >>>>>> define startup.icon to point to an existing image. >>>>>> >>>>>> The problem is that the splash screen gifs contain a string with the >>>>>> jtHarness version. So a more general solution would be to create such >>>>>> a gif as part of the build (e.g. from a generic template). >>>>>> >>>>>> I think this a "day-zero" problem (at lease from the day the jtHarness >>>>>> sources are in the OpenJDK Mercurial repositories) but has never been >>>>>> encountered because people usually used pre-built version of jtHarness >>>>>> from Oracle which contain a valid "splash.gif" icon. >>>>>> >>>>>> Now, with the new jtReg build script "make/buiild-all.sh" which makes >>>>>> it easy for everybody to build jtReg and all its dependencies >>>>>> (including jtHarness) from source this problem will affect everybody >>>>>> who does so! >> From jonathan.gibbons at oracle.com Mon Jan 29 19:50:29 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 29 Jan 2018 11:50:29 -0800 Subject: CFV: New Code Tools Committer: Shura Iline Message-ID: <5A6F7B05.8090607@oracle.com> |I hereby nominate Alexandre (Shura) Iline to Code Tools Committer. As well as his other work for JDK and JDK quality, Shura is the original author of and primary contributor to the Code Tools "Jemmy" repositories. ||| http://hg.openjdk.java.net/code-tools/jemmy/v2/|||| http://hg.openjdk.java.net/code-tools/jemmy/v3/ |Votes are due by the noon PST, February 12th. Only current Code Tools Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. -- Jonathan Gibbons [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote| From jonathan.gibbons at oracle.com Mon Jan 29 19:51:06 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 29 Jan 2018 11:51:06 -0800 Subject: CFV: New Code Tools Committer: Shura Iline In-Reply-To: <5A6F7B05.8090607@oracle.com> References: <5A6F7B05.8090607@oracle.com> Message-ID: <5A6F7B2A.1090803@oracle.com> Vote: yes -- Jon On 01/29/2018 11:50 AM, Jonathan Gibbons wrote: > |I hereby nominate Alexandre (Shura) Iline to Code Tools Committer. > > As well as his other work for JDK and JDK quality, Shura is the original > author of and primary contributor to the Code Tools "Jemmy" repositories. > ||| > http://hg.openjdk.java.net/code-tools/jemmy/v2/|||| > http://hg.openjdk.java.net/code-tools/jemmy/v3/ > > |Votes are due by the noon PST, February 12th. > > Only current Code Tools Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > -- Jonathan Gibbons > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote| > From kevin.looney at oracle.com Mon Jan 29 20:11:43 2018 From: kevin.looney at oracle.com (Kevin Looney) Date: Mon, 29 Jan 2018 12:11:43 -0800 Subject: CFV: New Code Tools Committer: Shura Iline In-Reply-To: <5A6F7B05.8090607@oracle.com> References: <5A6F7B05.8090607@oracle.com> Message-ID: <4c49048c-96ad-b415-7401-ce0bce902cef@oracle.com> Vote: Yes On 1/29/18 11:50 AM, Jonathan Gibbons wrote: > |I hereby nominate Alexandre (Shura) Iline to Code Tools Committer. > > As well as his other work for JDK and JDK quality, Shura is the original > author of and primary contributor to the Code Tools "Jemmy" repositories. > ||| > http://hg.openjdk.java.net/code-tools/jemmy/v2/|||| > http://hg.openjdk.java.net/code-tools/jemmy/v3/ > > |Votes are due by the noon PST, February 12th. > > Only current Code Tools Committers [1] are eligible to vote > on this nomination.? Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > -- Jonathan Gibbons > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote| > -- kevin.looney at oracle.com From iris.clark at oracle.com Mon Jan 29 20:12:24 2018 From: iris.clark at oracle.com (Iris Clark) Date: Mon, 29 Jan 2018 12:12:24 -0800 (PST) Subject: CFV: New Code Tools Committer: Shura Iline In-Reply-To: <5A6F7B05.8090607@oracle.com> References: <5A6F7B05.8090607@oracle.com> Message-ID: <17491156-8a1c-43d6-ade6-f46e4b8e04f1@default> Vote: yes iris From alexey.fedorchenko at oracle.com Tue Jan 30 09:37:56 2018 From: alexey.fedorchenko at oracle.com (Alexey Fedorchenko) Date: Tue, 30 Jan 2018 12:37:56 +0300 Subject: CFV: New Code Tools Committer: Shura Iline In-Reply-To: <5A6F7B05.8090607@oracle.com> References: <5A6F7B05.8090607@oracle.com> Message-ID: <38668A9C-145B-4463-BFA0-1A526ABA3993@oracle.com> Vote: yes -- Alexey > On Jan 29, 2018, at 10:50 PM, Jonathan Gibbons wrote: > > |I hereby nominate Alexandre (Shura) Iline to Code Tools Committer. > > As well as his other work for JDK and JDK quality, Shura is the original > author of and primary contributor to the Code Tools "Jemmy" repositories. > ||| > http://hg.openjdk.java.net/code-tools/jemmy/v2/|||| > http://hg.openjdk.java.net/code-tools/jemmy/v3/ > > |Votes are due by the noon PST, February 12th. > > Only current Code Tools Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > -- Jonathan Gibbons > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote| >