Re: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool]
Jörg, I don't think it will be very much work to bring service bundler code from JFX packager into OpenJDK jpackager. Though I can't give you estimates on amount of work needed to be done for this at the moment. - Alexey On 7/23/2018 7:47 AM, Buchberger, Joerg wrote: Thanks for the insight. @Alexey: Then, how much work do you see in reactivating service bundler? Cheers Jörg -Original Message- From: Kevin Rushforth [mailto:kevin.rushfo...@oracle.com] Sent: Donnerstag, 12. Juli 2018 01:09 To: Buchberger, Joerg ; core-libs-dev@openjdk.java.net Cc: Alexey Semenyuk ; Andy Herrick Subject: Re: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool] We will likely be able to deliver the .exe installer (with its dependency on Inno Setup). As for the service bundler, this will be a "nice to have" (a stretch goal) for this version, but isn't on the list of committed features. Alexsei might be able to comment further on how much work it would be to provide it, including documenting and testing it. This might give you, and other interested developers, a sense of how likely this is to make it for this version. -- Kevin On 7/10/2018 4:35 AM, Buchberger, Joerg wrote: Hi thanks for the update/info. I had a quick look at the changes. So, here some thoughts... As described in JDK-8200758, and therefore expected, WinExeBundler has been removed in favor of putting focus on WinMsiBundler. (Although, I regret that decision - since my personal experience has been that InnoSetup based WinExeBundler has worked much better than wix based WinMsiBundler for our use cases - I can live with that.) What is much more disturbing: WinServiceBundler has also been actively removed, although that was working fine together with both wix/msi and exe/iss. Why has service wrapping been removed as well, while the command line option for it is kept in place? Is there any chance of service bundler coming back into scope of JDK-8200758 or coming back in at all? Cheers Jörg -Original Message- From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf Of Kevin Rushforth Sent: Freitag, 6. Juli 2018 22:14 To: core-libs-dev@openjdk.java.net Cc: Alexey Semenyuk ; Andy Herrick Subject: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool] An initial prototype of the jpackager tool has been pushed to a new 'JDK-8200758-branch' branch in the JDK sandbox [1]. If anyone is interested in taking a look, you can clone it as follows: hg clone https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.net_jdk_sandbox=DwIFaQ=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxRW_bPSUkfEI=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg=jWWENz_KIkmyh-9-kQQvoZ0BwBymwQ-BKx8hG3F5Iy0= cd ./sandbox hg update JDK-8200758-branch I plan to reply to the feedback already provided, and update the JEP [2] next week some time, but in the mean time if you have additional questions or comments, feel free to reply. -- Kevin [1] https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.ne t_jdk_sandbox_shortlog_JDK-2D8200758-2Dbranch=DwIFaQ=uD3W7j5M6i1jD eSybgeVwm110GaiTFmxRW_bPSUkfEI=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJK hVEy_Q=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg=F-CqPAWlz-Cfb0k ae2FBEj4Ncd3ZBVu7BeOVY1AM-cA= [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java .net_browse_JDK-2D8200758=DwIFaQ=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxR W_bPSUkfEI=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q=7aoiG26qKHq hAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg=DFIAHtCR1o--KMLuBzurIzx5MDu67NgtUrE dQ22wI9I= On 6/27/2018 3:30 PM, Kevin Rushforth wrote: We're aiming to get this into JDK 12 early enough so that an EA build would be available around the time JDK 11 ships. That will allow you to take a jlinked image with JDK 11 and package it up using (the EA) jpackager. We will create a development branch in the JDK sandbox [1] some time in the next week or so so you can follow the development. Also, thank you to those who have provided feedback. I'll reply to feedback soon and then incorporate it into an updated JEP. -- Kevin
RE: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool]
Thanks for the insight. @Alexey: Then, how much work do you see in reactivating service bundler? Cheers Jörg -Original Message- From: Kevin Rushforth [mailto:kevin.rushfo...@oracle.com] Sent: Donnerstag, 12. Juli 2018 01:09 To: Buchberger, Joerg ; core-libs-dev@openjdk.java.net Cc: Alexey Semenyuk ; Andy Herrick Subject: Re: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool] We will likely be able to deliver the .exe installer (with its dependency on Inno Setup). As for the service bundler, this will be a "nice to have" (a stretch goal) for this version, but isn't on the list of committed features. Alexsei might be able to comment further on how much work it would be to provide it, including documenting and testing it. This might give you, and other interested developers, a sense of how likely this is to make it for this version. -- Kevin On 7/10/2018 4:35 AM, Buchberger, Joerg wrote: > Hi > > thanks for the update/info. I had a quick look at the changes. So, here some > thoughts... > > As described in JDK-8200758, and therefore expected, WinExeBundler has been > removed in favor of putting focus on WinMsiBundler. > (Although, I regret that decision - since my personal experience has > been that InnoSetup based WinExeBundler has worked much better than > wix based WinMsiBundler for our use cases - I can live with that.) > > What is much more disturbing: WinServiceBundler has also been actively > removed, although that was working fine together with both wix/msi and > exe/iss. Why has service wrapping been removed as well, while the command > line option for it is kept in place? > > Is there any chance of service bundler coming back into scope of JDK-8200758 > or coming back in at all? > > Cheers > Jörg > > > -Original Message- > From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On > Behalf Of Kevin Rushforth > Sent: Freitag, 6. Juli 2018 22:14 > To: core-libs-dev@openjdk.java.net > Cc: Alexey Semenyuk ; Andy Herrick > > Subject: Prototype of jpackager in jdk/sandbox [was: Draft JEP > proposal: JDK-8200758: Packaging Tool] > > An initial prototype of the jpackager tool has been pushed to a new > 'JDK-8200758-branch' branch in the JDK sandbox [1]. If anyone is interested > in taking a look, you can clone it as follows: > > hg clone > https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.net_jdk_sandbox=DwIFaQ=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxRW_bPSUkfEI=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg=jWWENz_KIkmyh-9-kQQvoZ0BwBymwQ-BKx8hG3F5Iy0= > cd ./sandbox > hg update JDK-8200758-branch > > I plan to reply to the feedback already provided, and update the JEP [2] next > week some time, but in the mean time if you have additional questions or > comments, feel free to reply. > > -- Kevin > > [1] > https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.ne > t_jdk_sandbox_shortlog_JDK-2D8200758-2Dbranch=DwIFaQ=uD3W7j5M6i1jD > eSybgeVwm110GaiTFmxRW_bPSUkfEI=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJK > hVEy_Q=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg=F-CqPAWlz-Cfb0k > ae2FBEj4Ncd3ZBVu7BeOVY1AM-cA= [2] > https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java > .net_browse_JDK-2D8200758=DwIFaQ=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxR > W_bPSUkfEI=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q=7aoiG26qKHq > hAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg=DFIAHtCR1o--KMLuBzurIzx5MDu67NgtUrE > dQ22wI9I= > > > On 6/27/2018 3:30 PM, Kevin Rushforth wrote: >> We're aiming to get this into JDK 12 early enough so that an EA build >> would be available around the time JDK 11 ships. That will allow you >> to take a jlinked image with JDK 11 and package it up using (the EA) >> jpackager. >> >> We will create a development branch in the JDK sandbox [1] some time >> in the next week or so so you can follow the development. >> >> Also, thank you to those who have provided feedback. I'll reply to >> feedback soon and then incorporate it into an updated JEP. >> >> -- Kevin
Re: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool]
Since support for services/daemons was already in javapackager, why does this have to be a stretch goal? Isn’t it mostly already done? I would like to see this in the initial implementation. It is something I’m currently using via javapackager. I’m still trying to figure out the best strategy from bridging the gap in Java 11 where suddenly no packager is available. My company has already decided to skip Java 9 and 10 altogether. Modules were too disruptive when they came in Java 9, which didn’t last long until Java 10. Given that Java 11 unbundled JavaFX, we decided not to bother trying to go to 10 just to have to re-jig everything for 11. Now 11 is missing key tools (javapackager) that we began to rely on, so we keep falling behind, unable to adopt the newer JDK/JRE because the cost is so high. The first time ever in the history of Java where we couldn’t just adapt the new JDK and tweak for minor issues if any. Migrating projects beyond Java 8 is a big pain. It would suck if Java 12 lacks what was available in Java 8. (Please excuse the rant.) Scott > On Jul 11, 2018, at 7:08 PM, Kevin Rushforth > wrote: > > We will likely be able to deliver the .exe installer (with its dependency on > Inno Setup). > > As for the service bundler, this will be a "nice to have" (a stretch goal) > for this version, but isn't on the list of committed features. Alexsei might > be able to comment further on how much work it would be to provide it, > including documenting and testing it. This might give you, and other > interested developers, a sense of how likely this is to make it for this > version. > > -- Kevin > > >> On 7/10/2018 4:35 AM, Buchberger, Joerg wrote: >> Hi >> >> thanks for the update/info. I had a quick look at the changes. So, here some >> thoughts... >> >> As described in JDK-8200758, and therefore expected, WinExeBundler has been >> removed in favor of putting focus on WinMsiBundler. >> (Although, I regret that decision - since my personal experience has been >> that InnoSetup based WinExeBundler has worked much better than wix based >> WinMsiBundler for our use cases - I can live with that.) >> >> What is much more disturbing: WinServiceBundler has also been actively >> removed, although that was working fine together with both wix/msi and >> exe/iss. Why has service wrapping been removed as well, while the command >> line option for it is kept in place? >> >> Is there any chance of service bundler coming back into scope of JDK-8200758 >> or coming back in at all? >> >> Cheers >> Jörg >> >> >> -Original Message- >> From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On >> Behalf Of Kevin Rushforth >> Sent: Freitag, 6. Juli 2018 22:14 >> To: core-libs-dev@openjdk.java.net >> Cc: Alexey Semenyuk ; Andy Herrick >> >> Subject: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: >> JDK-8200758: Packaging Tool] >> >> An initial prototype of the jpackager tool has been pushed to a new >> 'JDK-8200758-branch' branch in the JDK sandbox [1]. If anyone is interested >> in taking a look, you can clone it as follows: >> >> hg clone >> https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.net_jdk_sandbox=DwIFaQ=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxRW_bPSUkfEI=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg=jWWENz_KIkmyh-9-kQQvoZ0BwBymwQ-BKx8hG3F5Iy0= >> cd ./sandbox >> hg update JDK-8200758-branch >> >> I plan to reply to the feedback already provided, and update the JEP [2] >> next week some time, but in the mean time if you have additional questions >> or comments, feel free to reply. >> >> -- Kevin >> >> [1] >> https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.net_jdk_sandbox_shortlog_JDK-2D8200758-2Dbranch=DwIFaQ=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxRW_bPSUkfEI=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg=F-CqPAWlz-Cfb0kae2FBEj4Ncd3ZBVu7BeOVY1AM-cA= >> [2] >> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8200758=DwIFaQ=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxRW_bPSUkfEI=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg=DFIAHtCR1o--KMLuBzurIzx5MDu67NgtUrEdQ22wI9I= >> >> >>> On 6/27/2018 3:30 PM, Kevin Rushforth wrote: >>> We're aiming to get this into JDK 12 early enough so that an EA build >>> would be available around the time JDK 11 ships. That will allow you >>> to take a jlinked image with JDK 11 and package it up using (the EA) >>> jpackager. >>> >>> We will create a development branch in the JDK sandbox [1] some time >>> in the next week or so so you can follow the development. >>> >>> Also, thank you to those who have provided feedback. I'll reply to >>> feedback soon and then incorporate it into an updated JEP. >>> >>> -- Kevin >
Re: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool]
We will likely be able to deliver the .exe installer (with its dependency on Inno Setup). As for the service bundler, this will be a "nice to have" (a stretch goal) for this version, but isn't on the list of committed features. Alexsei might be able to comment further on how much work it would be to provide it, including documenting and testing it. This might give you, and other interested developers, a sense of how likely this is to make it for this version. -- Kevin On 7/10/2018 4:35 AM, Buchberger, Joerg wrote: Hi thanks for the update/info. I had a quick look at the changes. So, here some thoughts... As described in JDK-8200758, and therefore expected, WinExeBundler has been removed in favor of putting focus on WinMsiBundler. (Although, I regret that decision - since my personal experience has been that InnoSetup based WinExeBundler has worked much better than wix based WinMsiBundler for our use cases - I can live with that.) What is much more disturbing: WinServiceBundler has also been actively removed, although that was working fine together with both wix/msi and exe/iss. Why has service wrapping been removed as well, while the command line option for it is kept in place? Is there any chance of service bundler coming back into scope of JDK-8200758 or coming back in at all? Cheers Jörg -Original Message- From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf Of Kevin Rushforth Sent: Freitag, 6. Juli 2018 22:14 To: core-libs-dev@openjdk.java.net Cc: Alexey Semenyuk ; Andy Herrick Subject: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool] An initial prototype of the jpackager tool has been pushed to a new 'JDK-8200758-branch' branch in the JDK sandbox [1]. If anyone is interested in taking a look, you can clone it as follows: hg clone https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.net_jdk_sandbox=DwIFaQ=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxRW_bPSUkfEI=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg=jWWENz_KIkmyh-9-kQQvoZ0BwBymwQ-BKx8hG3F5Iy0= cd ./sandbox hg update JDK-8200758-branch I plan to reply to the feedback already provided, and update the JEP [2] next week some time, but in the mean time if you have additional questions or comments, feel free to reply. -- Kevin [1] https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.net_jdk_sandbox_shortlog_JDK-2D8200758-2Dbranch=DwIFaQ=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxRW_bPSUkfEI=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg=F-CqPAWlz-Cfb0kae2FBEj4Ncd3ZBVu7BeOVY1AM-cA= [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8200758=DwIFaQ=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxRW_bPSUkfEI=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg=DFIAHtCR1o--KMLuBzurIzx5MDu67NgtUrEdQ22wI9I= On 6/27/2018 3:30 PM, Kevin Rushforth wrote: We're aiming to get this into JDK 12 early enough so that an EA build would be available around the time JDK 11 ships. That will allow you to take a jlinked image with JDK 11 and package it up using (the EA) jpackager. We will create a development branch in the JDK sandbox [1] some time in the next week or so so you can follow the development. Also, thank you to those who have provided feedback. I'll reply to feedback soon and then incorporate it into an updated JEP. -- Kevin
RE: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool]
Hi thanks for the update/info. I had a quick look at the changes. So, here some thoughts... As described in JDK-8200758, and therefore expected, WinExeBundler has been removed in favor of putting focus on WinMsiBundler. (Although, I regret that decision - since my personal experience has been that InnoSetup based WinExeBundler has worked much better than wix based WinMsiBundler for our use cases - I can live with that.) What is much more disturbing: WinServiceBundler has also been actively removed, although that was working fine together with both wix/msi and exe/iss. Why has service wrapping been removed as well, while the command line option for it is kept in place? Is there any chance of service bundler coming back into scope of JDK-8200758 or coming back in at all? Cheers Jörg -Original Message- From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf Of Kevin Rushforth Sent: Freitag, 6. Juli 2018 22:14 To: core-libs-dev@openjdk.java.net Cc: Alexey Semenyuk ; Andy Herrick Subject: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool] An initial prototype of the jpackager tool has been pushed to a new 'JDK-8200758-branch' branch in the JDK sandbox [1]. If anyone is interested in taking a look, you can clone it as follows: hg clone https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.net_jdk_sandbox=DwIFaQ=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxRW_bPSUkfEI=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg=jWWENz_KIkmyh-9-kQQvoZ0BwBymwQ-BKx8hG3F5Iy0= cd ./sandbox hg update JDK-8200758-branch I plan to reply to the feedback already provided, and update the JEP [2] next week some time, but in the mean time if you have additional questions or comments, feel free to reply. -- Kevin [1] https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.net_jdk_sandbox_shortlog_JDK-2D8200758-2Dbranch=DwIFaQ=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxRW_bPSUkfEI=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg=F-CqPAWlz-Cfb0kae2FBEj4Ncd3ZBVu7BeOVY1AM-cA= [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8200758=DwIFaQ=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxRW_bPSUkfEI=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg=DFIAHtCR1o--KMLuBzurIzx5MDu67NgtUrEdQ22wI9I= On 6/27/2018 3:30 PM, Kevin Rushforth wrote: > We're aiming to get this into JDK 12 early enough so that an EA build > would be available around the time JDK 11 ships. That will allow you > to take a jlinked image with JDK 11 and package it up using (the EA) > jpackager. > > We will create a development branch in the JDK sandbox [1] some time > in the next week or so so you can follow the development. > > Also, thank you to those who have provided feedback. I'll reply to > feedback soon and then incorporate it into an updated JEP. > > -- Kevin
Re: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool]
For the first point, it means that jpackager should use jopt for the argument
parsing (to be fully compatible with the GNU style of options).
For the second point, it means to change a lot of code that may break because
it's less mechanical than introducing try-with-resources.
This seems quite a reasonable suggestion. Thanks.
-- Kevin
On 7/7/2018 7:10 AM, fo...@univ-mlv.fr wrote:
- Mail original -
De: "Kevin Rushforth"
À: "Remi Forax"
Cc: "core-libs-dev" , "Alexey Semenyuk"
, "Andy Herrick"
Envoyé: Samedi 7 Juillet 2018 15:47:01
Objet: Re: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal:
JDK-8200758: Packaging Tool]
Hi Remy,
Thank you for taking a look.
Yes, the javapackager code that forms the basis for the jpackager
prototype was initially developed on older JDKs and evolved from there.
I'm sure the improvements you suggest are all good ones, and it doesn't
seem like it would be too hard to address the most important of them,
especially the try-with-resources or anything else that would affect the
robustness of the tool. As long as we do address the robustness issues,
I think it is more important to get the feature set right, and make sure
that the public interfaces -- the command line options and ToolProvider
interface -- are clean. I don't see the need to rewrite the tool or take
an extra couple of months to modernize all of the implementation to use
JDK 11 APIs everywhere.
Also, I don't agree that jpackager is too large for jdk/sandbox or that
it needs it own project. The jdk/sandbox is perfect for new modules /
new tools that don't impact other parts of the JDK.
-- Kevin
Hi Kevin,
like you, i don't think that a full rewrite is necessary, as you said having
the right public 'interfaces' is enough,
but reducing the size the duplicated code (with the JDK and internally) is as
important in my opinion.
For the first point, it means that jpackager should use jopt for the argument
parsing (to be fully compatible with the GNU style of options).
For the second point, it means to change a lot of code that may break because
it's less mechanical than introducing try-with-resources.
regards,
Rémi
On 7/6/2018 3:07 PM, Remi Forax wrote:
I've just taking a look at the patch,
i don't see how this can be integrated soon, the code is consistently
inconsistent as one of my colleague would say, even the coding conventions are
not respected.
i believe that's it's because the code have been written first in Java 6 an
without refactoring was moved to use Java 7, 8, 9, 10 and 11.
The I/O code still using java.io.File for some parts, no try-with-resources so
most of the try/finally are not safe,
a lot of code like new BufferedWriter(new FileWriter(file)) instead of
Files.newBufferedWriter, etc. The code should use the package java.nio.file,
and not the old java.io,
most of the code try to manage the exception right were they appear instead of
propagating them so there are too many try/catch,
a lot of catch are ignored which is a code smell, some codes use the internal
logger (jdk.packager.internal.Log), but a lot of codes doesn't,
for the collection code, there is a lot of copy of data small structures (which
suggest that published collections are not immutable),
there are dubious @SuppressWarnings("unchecked"), some or them are due to the
fact that the code use Class as a type token instead of using lambdas,
Stream are not used when they should (to avoid multiple copy between data
structures) and streams that need to be closed are not (the result of
Files.list by example),
there are usual "don't do that in Java" like a loop using an integer index to
traverse a List without knowing if it's a random access list or not,
there is a lot of nullchecks instead of using Optional,
a lot of code initialize local variables to null which is a code smell (and a
side effect of having a lot of try/catch but not only),
constructors should not do work, just initialization, use static factory method
instead (so you will not have to debug half constructed objects),
the code uses BigIntegers to parse a bundle version, just in case,
the code uses an AtomicReference as a box that a lambda can mutate, instead of
wrapping the exception into a runtime and unwrapping it at call site,
The code of jdk.packager.internal.IOUtils should be updated to use methods of
the JDK 11 and methods like readFully should be replaced by the JDK's one.
listOfPathToString and setOfStringToString are just WTF, like in
getRedistributableModules(), where the variable stream is an Optional,
A class like Platform should be used everywhere to do platform specific stuff, a
lot of code still use String matching (the version parsing should use
System.Version).
All the argument parsing should be delegated to JOpt (the one integrated with
the JDK), so it will be consistent with the other JDK tools,
There is a UnsupportedPlatformException but a Platform can be UNKOWN ??
I will stop here, my point is that there is a lot of
Re: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool]
- Mail original -
> De: "Kevin Rushforth"
> À: "Remi Forax"
> Cc: "core-libs-dev" , "Alexey Semenyuk"
> , "Andy Herrick"
>
> Envoyé: Samedi 7 Juillet 2018 15:47:01
> Objet: Re: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal:
> JDK-8200758: Packaging Tool]
> Hi Remy,
>
> Thank you for taking a look.
>
> Yes, the javapackager code that forms the basis for the jpackager
> prototype was initially developed on older JDKs and evolved from there.
> I'm sure the improvements you suggest are all good ones, and it doesn't
> seem like it would be too hard to address the most important of them,
> especially the try-with-resources or anything else that would affect the
> robustness of the tool. As long as we do address the robustness issues,
> I think it is more important to get the feature set right, and make sure
> that the public interfaces -- the command line options and ToolProvider
> interface -- are clean. I don't see the need to rewrite the tool or take
> an extra couple of months to modernize all of the implementation to use
> JDK 11 APIs everywhere.
>
> Also, I don't agree that jpackager is too large for jdk/sandbox or that
> it needs it own project. The jdk/sandbox is perfect for new modules /
> new tools that don't impact other parts of the JDK.
>
> -- Kevin
Hi Kevin,
like you, i don't think that a full rewrite is necessary, as you said having
the right public 'interfaces' is enough,
but reducing the size the duplicated code (with the JDK and internally) is as
important in my opinion.
For the first point, it means that jpackager should use jopt for the argument
parsing (to be fully compatible with the GNU style of options).
For the second point, it means to change a lot of code that may break because
it's less mechanical than introducing try-with-resources.
regards,
Rémi
>
>
> On 7/6/2018 3:07 PM, Remi Forax wrote:
>> I've just taking a look at the patch,
>> i don't see how this can be integrated soon, the code is consistently
>> inconsistent as one of my colleague would say, even the coding conventions
>> are
>> not respected.
>> i believe that's it's because the code have been written first in Java 6 an
>> without refactoring was moved to use Java 7, 8, 9, 10 and 11.
>>
>> The I/O code still using java.io.File for some parts, no try-with-resources
>> so
>> most of the try/finally are not safe,
>> a lot of code like new BufferedWriter(new FileWriter(file)) instead of
>> Files.newBufferedWriter, etc. The code should use the package java.nio.file,
>> and not the old java.io,
>> most of the code try to manage the exception right were they appear instead
>> of
>> propagating them so there are too many try/catch,
>> a lot of catch are ignored which is a code smell, some codes use the internal
>> logger (jdk.packager.internal.Log), but a lot of codes doesn't,
>> for the collection code, there is a lot of copy of data small structures
>> (which
>> suggest that published collections are not immutable),
>> there are dubious @SuppressWarnings("unchecked"), some or them are due to the
>> fact that the code use Class as a type token instead of using lambdas,
>> Stream are not used when they should (to avoid multiple copy between data
>> structures) and streams that need to be closed are not (the result of
>> Files.list by example),
>> there are usual "don't do that in Java" like a loop using an integer index to
>> traverse a List without knowing if it's a random access list or not,
>> there is a lot of nullchecks instead of using Optional,
>> a lot of code initialize local variables to null which is a code smell (and a
>> side effect of having a lot of try/catch but not only),
>> constructors should not do work, just initialization, use static factory
>> method
>> instead (so you will not have to debug half constructed objects),
>> the code uses BigIntegers to parse a bundle version, just in case,
>> the code uses an AtomicReference as a box that a lambda can mutate, instead
>> of
>> wrapping the exception into a runtime and unwrapping it at call site,
>> The code of jdk.packager.internal.IOUtils should be updated to use methods of
>> the JDK 11 and methods like readFully should be replaced by the JDK's one.
>> listOfPathToString and setOfStringToString are just WTF, like in
>> getRedistributableModules(), where the variable stream is an Optional,
>> A class like Platform should be used everywhere to do platform specific
>> stuff, a
>> lot of code still use String matching (the version parsing should use
>> System.Version).
>> All the argument parsing should be delegated to JOpt (the one integrated with
>> the JDK), so it will be consistent with the other JDK tools,
>> There is a UnsupportedPlatformException but a Platform can be UNKOWN ??
>>
>> I will stop here, my point is that there is a lot of cleaning that should
>> appear
>> before the code is integrated into the JDK and given the size of the code, i
>> wonder if it's not better to start an OpenJDK project
Re: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool]
Hi Remy,
Thank you for taking a look.
Yes, the javapackager code that forms the basis for the jpackager
prototype was initially developed on older JDKs and evolved from there.
I'm sure the improvements you suggest are all good ones, and it doesn't
seem like it would be too hard to address the most important of them,
especially the try-with-resources or anything else that would affect the
robustness of the tool. As long as we do address the robustness issues,
I think it is more important to get the feature set right, and make sure
that the public interfaces -- the command line options and ToolProvider
interface -- are clean. I don't see the need to rewrite the tool or take
an extra couple of months to modernize all of the implementation to use
JDK 11 APIs everywhere.
Also, I don't agree that jpackager is too large for jdk/sandbox or that
it needs it own project. The jdk/sandbox is perfect for new modules /
new tools that don't impact other parts of the JDK.
-- Kevin
On 7/6/2018 3:07 PM, Remi Forax wrote:
I've just taking a look at the patch,
i don't see how this can be integrated soon, the code is consistently
inconsistent as one of my colleague would say, even the coding conventions are
not respected.
i believe that's it's because the code have been written first in Java 6 an
without refactoring was moved to use Java 7, 8, 9, 10 and 11.
The I/O code still using java.io.File for some parts, no try-with-resources so
most of the try/finally are not safe,
a lot of code like new BufferedWriter(new FileWriter(file)) instead of
Files.newBufferedWriter, etc. The code should use the package java.nio.file,
and not the old java.io,
most of the code try to manage the exception right were they appear instead of
propagating them so there are too many try/catch,
a lot of catch are ignored which is a code smell, some codes use the internal
logger (jdk.packager.internal.Log), but a lot of codes doesn't,
for the collection code, there is a lot of copy of data small structures (which
suggest that published collections are not immutable),
there are dubious @SuppressWarnings("unchecked"), some or them are due to the
fact that the code use Class as a type token instead of using lambdas,
Stream are not used when they should (to avoid multiple copy between data
structures) and streams that need to be closed are not (the result of
Files.list by example),
there are usual "don't do that in Java" like a loop using an integer index to
traverse a List without knowing if it's a random access list or not,
there is a lot of nullchecks instead of using Optional,
a lot of code initialize local variables to null which is a code smell (and a
side effect of having a lot of try/catch but not only),
constructors should not do work, just initialization, use static factory method
instead (so you will not have to debug half constructed objects),
the code uses BigIntegers to parse a bundle version, just in case,
the code uses an AtomicReference as a box that a lambda can mutate, instead of
wrapping the exception into a runtime and unwrapping it at call site,
The code of jdk.packager.internal.IOUtils should be updated to use methods of
the JDK 11 and methods like readFully should be replaced by the JDK's one.
listOfPathToString and setOfStringToString are just WTF, like in
getRedistributableModules(), where the variable stream is an Optional,
A class like Platform should be used everywhere to do platform specific stuff,
a lot of code still use String matching (the version parsing should use
System.Version).
All the argument parsing should be delegated to JOpt (the one integrated with
the JDK), so it will be consistent with the other JDK tools,
There is a UnsupportedPlatformException but a Platform can be UNKOWN ??
I will stop here, my point is that there is a lot of cleaning that should
appear before the code is integrated into the JDK and given the size of the
code, i wonder if it's not better to start an OpenJDK project for it and
iterate on the code before trying to include it in the JDK. For me, the code is
too big to use the jdk/sandbox.
regards,
Rémi
- Mail original -
De: "Kevin Rushforth"
À: "core-libs-dev"
Cc: "Alexey Semenyuk" , "Andy Herrick"
Envoyé: Vendredi 6 Juillet 2018 22:14:29
Objet: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal:
JDK-8200758: Packaging Tool]
An initial prototype of the jpackager tool has been pushed to a new
'JDK-8200758-branch' branch in the JDK sandbox [1]. If anyone is
interested in taking a look, you can clone it as follows:
hg clone http://hg.openjdk.java.net/jdk/sandbox
cd ./sandbox
hg update JDK-8200758-branch
I plan to reply to the feedback already provided, and update the JEP [2]
next week some time, but in the mean time if you have additional
questions or comments, feel free to reply.
-- Kevin
[1] http://hg.openjdk.java.net/jdk/sandbox/shortlog/JDK-8200758-branch
[2]
Re: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool]
I've just taking a look at the patch,
i don't see how this can be integrated soon, the code is consistently
inconsistent as one of my colleague would say, even the coding conventions are
not respected.
i believe that's it's because the code have been written first in Java 6 an
without refactoring was moved to use Java 7, 8, 9, 10 and 11.
The I/O code still using java.io.File for some parts, no try-with-resources so
most of the try/finally are not safe,
a lot of code like new BufferedWriter(new FileWriter(file)) instead of
Files.newBufferedWriter, etc. The code should use the package java.nio.file,
and not the old java.io,
most of the code try to manage the exception right were they appear instead of
propagating them so there are too many try/catch,
a lot of catch are ignored which is a code smell, some codes use the internal
logger (jdk.packager.internal.Log), but a lot of codes doesn't,
for the collection code, there is a lot of copy of data small structures (which
suggest that published collections are not immutable),
there are dubious @SuppressWarnings("unchecked"), some or them are due to the
fact that the code use Class as a type token instead of using lambdas,
Stream are not used when they should (to avoid multiple copy between data
structures) and streams that need to be closed are not (the result of
Files.list by example),
there are usual "don't do that in Java" like a loop using an integer index to
traverse a List without knowing if it's a random access list or not,
there is a lot of nullchecks instead of using Optional,
a lot of code initialize local variables to null which is a code smell (and a
side effect of having a lot of try/catch but not only),
constructors should not do work, just initialization, use static factory method
instead (so you will not have to debug half constructed objects),
the code uses BigIntegers to parse a bundle version, just in case,
the code uses an AtomicReference as a box that a lambda can mutate, instead of
wrapping the exception into a runtime and unwrapping it at call site,
The code of jdk.packager.internal.IOUtils should be updated to use methods of
the JDK 11 and methods like readFully should be replaced by the JDK's one.
listOfPathToString and setOfStringToString are just WTF, like in
getRedistributableModules(), where the variable stream is an Optional,
A class like Platform should be used everywhere to do platform specific stuff,
a lot of code still use String matching (the version parsing should use
System.Version).
All the argument parsing should be delegated to JOpt (the one integrated with
the JDK), so it will be consistent with the other JDK tools,
There is a UnsupportedPlatformException but a Platform can be UNKOWN ??
I will stop here, my point is that there is a lot of cleaning that should
appear before the code is integrated into the JDK and given the size of the
code, i wonder if it's not better to start an OpenJDK project for it and
iterate on the code before trying to include it in the JDK. For me, the code is
too big to use the jdk/sandbox.
regards,
Rémi
- Mail original -
> De: "Kevin Rushforth"
> À: "core-libs-dev"
> Cc: "Alexey Semenyuk" , "Andy Herrick"
>
> Envoyé: Vendredi 6 Juillet 2018 22:14:29
> Objet: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal:
> JDK-8200758: Packaging Tool]
> An initial prototype of the jpackager tool has been pushed to a new
> 'JDK-8200758-branch' branch in the JDK sandbox [1]. If anyone is
> interested in taking a look, you can clone it as follows:
>
> hg clone http://hg.openjdk.java.net/jdk/sandbox
> cd ./sandbox
> hg update JDK-8200758-branch
>
> I plan to reply to the feedback already provided, and update the JEP [2]
> next week some time, but in the mean time if you have additional
> questions or comments, feel free to reply.
>
> -- Kevin
>
> [1] http://hg.openjdk.java.net/jdk/sandbox/shortlog/JDK-8200758-branch
> [2] https://bugs.openjdk.java.net/browse/JDK-8200758
>
>
> On 6/27/2018 3:30 PM, Kevin Rushforth wrote:
>> We're aiming to get this into JDK 12 early enough so that an EA build
>> would be available around the time JDK 11 ships. That will allow you
>> to take a jlinked image with JDK 11 and package it up using (the EA)
>> jpackager.
>>
>> We will create a development branch in the JDK sandbox [1] some time
>> in the next week or so so you can follow the development.
>>
>> Also, thank you to those who have provided feedback. I'll reply to
>> feedback soon and then incorporate it into an updated JEP.
>>
> > -- Kevin
