> On Oct 7, 2015, at 1:22 PM, Scott Selvia <ssel...@gmail.com> wrote: > > I would like to request an enhancement to have the packager support a Windows > Store application bundle as it currently supports the Mac App store package > process. > > I ask this question without checking the code availability, is the packager > code open sourced for others to contribute?
The source code is all GPL+Classpath: The current released code is http://hg.openjdk.java.net/openjfx/8u-dev/rt/ <http://hg.openjdk.java.net/openjfx/8u-dev/rt/> and the main packager bits are here http://hg.openjdk.java.net/openjfx/8u-dev/rt/file/761213753af4/modules/fxpackager <http://hg.openjdk.java.net/openjfx/8u-dev/rt/file/761213753af4/modules/fxpackager>. I'm working on some jigsaw updates and the will be here when ready: http://hg.openjdk.java.net/openjfx/sandbox-9-jake/ <http://hg.openjdk.java.net/openjfx/sandbox-9-jake/> > It would be really nice to automate the windows store code process, it is > not that dissimilar (makeappx, having an appxmanifest.xml (aka entitlements), > sign tool, etc..) The main problem is a very basic on. I haven't checked the Windows 10 store, but in the windows 8 and Windows 8.1 timeframe all windows app store apps had to be WinRT applications, and Java is Win32. I think WinRT has been re-named to be Universal Applications. The problem is very deep, however. One of the key constraints of WinRT was that like iOS you were prohibited from generating code and running it from the same app. (technically you couldn't flip the NX bit on any pages to change them from data to code). This is Java and the HotSpot VM's modus operandi, to take java byte code, create native code, and flip the MX bit. It can run in all-interpreted mode but that is orders of magnitude slower. So there is a whole lot more to a windows store installer than looks like initially, and it has little to do with packaging. --Danno
