> On Jan 15, 2019, at 10:55 AM, Rachel Greenham <rac...@strangenoises.org> > wrote: > > My understanding was that this particular jdk build only exists for the sake > of getting jpackage out there into our hands (hence my point about putting it > out as a jlinked app instead),
True, which is a little different in and of itself, providing a JDK for a single command. I’m not that familiar yet with what jlink can do. How would it’s being a launchable app help in testing a command line tool? Is there some new magic way I haven’t heard of yet that jlink provides so that invoking something command line launches an app with the enclosing JDK? > and if you want to play with jdk13-ea in its own right, should probably get a > fresh one to do just that, as the one used in these jpackage builds is not > necessarily always going to be the most up to date, and also may have changes > needed by jpackage that haven't been accepted upstream yet. In fact the > latter seems almost likely to me as otherwise why not just include jpackage > in the ea builds now? This could be true. So far I’ve assumed any issues I’ve seen are general JDK changes and not build specific. But sometime that could be a bad assumption. > > From my point of view, it's easy enough to do this, and the only downside is > needing to exec it as its own process rather than invoke in-process via > ToolProvider from my usual buildsystem jdk, which I intend to move to doing > later when it is finally part of the JDK I'm actually building with. Wastes > disk space too, but don't care about that, have plenty. :-) I think you talked about some of what you’re doing in earlier posts. I might have to look at those closer. I had disk space concerns installing VirtualBox with Ubunutu and Windows 10. But so far I still have enough. Other than that I’m pretty happy I stumbled on VirtualBox. I can finally make some of my stuff crossplatform and with jpackage I might even get reasonable app’s for each platform.
