Re: Java Deployment (was Re: JavaFX 8 Progress)
Hi Mark, NetX is the component used by IcedTea-web, the open replacement for the JDK plugin. Is not formally part of OpenJDK, but Linux distribution use this, and us also compatible at least on Windows. OpenJDK itself doesn't have a plugin component. OpenJFX should work with IcedTea in theory, but I think the code does some assumption on what is available on the platform, so probably there is still some work to do to ensure perfect compliance. Cheers, Mario Il giorno 20/lug/2013 19:27, Mark Fortner phidia...@gmail.com ha scritto: Coincidentally, I was upgrading my ubuntu box recently and noticed that it installed NetX (an open source JNLP alternative by default). http://jnlp.sourceforge.net/netx/index.html I'm not sure what the status is and how this fits into the openjdk vision of the world. Cheers, Mark On Thu, Jul 18, 2013 at 11:41 PM, John C. Turnbull ozem...@ozemail.com.auwrote: What's the performance like? What version of Java does it support? Is it a subset of the JRE or complete? -Original Message- From: openjfx-dev-boun...@openjdk.java.net [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Sven Reimers Sent: Friday, 19 July 2013 15:01 To: Daniel Zwolenski Cc: openjfx-dev@openjdk.java.net; mike.ehrenberg@barchart.comEhrenberg; JeremyJongsma Subject: Re: Java Deployment (was Re: JavaFX 8 Progress) A Java Runtime on top of JavaScript - http://wiki.apidesign.org/wiki/Bck2Brwsr -Sven On Fri, Jul 19, 2013 at 12:37 AM, Daniel Zwolenski zon...@gmail.com wrote: Yes this is another option, basically running it on a server and then rendering on the client. JavaFX could be extended to do this. Another alternative is a 'java runtime' built on top of jscript (similar idea to the runtime being built for mobile, like robovm). In this cases jfx would run 100% in the browser on top of jscript. Another option is a runtime built for the native elements of each browser. Eg a runtime running on chrome's native interface, etc. All of the above would require a lot of work before being ready to use and likely would have some tradeoffs in terms of features or performance. The options I listed in the last email are in my opinion more achievable in the short term and generally give decent results. Right now, if you want to deploy jfx my pick suggestion would be completely avoid any of the oracle solutions and just pay the licence fee for install4j. Although I'd not seen jwrapper until just now and it could do with some looking into too. On 19/07/2013, at 8:10 AM, Mario Torre neugens.limasoftw...@gmail.com wrote: For Swing you can actually use CacioWeb, works quite well. Zero deployment, no VM needed, no plugin, just an HTML 5 capable browser. Doesn't work with JavaFX unfortunately. Cheers, Mario Il giorno 19/lug/2013 00:03, Daniel Zwolenski zon...@gmail.com ha scritto: There are definitely credible alternatives. The problem is currently the alternatives are not implemented well enough so web still ends up a contender just by being the only one able to stand up. And for the record I build both public facing apps and back-office apps and web deploy does not work well for either. I stopped using jfx because of deployment. I now build only webapps because of deployment. Credible alternatives: 1. Native bundlers, but we need: - auto updating so people can easily release patch updates - smaller co-bundled jre's so that the initial download and install is smooth and quick - better build tools to make this easier to integrate into a standard build process, with some solution for cross-platform build support or to at least minimize the pain 2. App stores: - ready to go right now for Mac but we don't have the tools and I think we need everything fully open sourced for licensing reasons (hard to say) - need to either pick one of the unofficial win app stores for pre-win8 support (there's a few), or build our own app store - we just need tools for building and deploying to app stores (not that hard) and cut down jre sizes again (app stores are an extension of cobundling approach). 3. Self-hosted 'app store' for corporate settings. install a small, native client on the machine that allows that user to download and install apps from your private server, with auto-updating, etc - we need to build one, not that hard, maybe a month or two of work to get a first working version out. I would have built one by now but because jfx packaging tools are so bad I've burnt up all my spare time just putting wrappers around these to get the most basic of maven plugins to work. All of the above could have been implemented by now if there was just a little bit
Re: Java Deployment (was Re: JavaFX 8 Progress)
So you're saying, once I create my new JavaFX app with all the new beautiful and wondrous JavaFX goodies - I can do what? Sit at home and look at it? :) David On Jul 18, 2013, at 5:02 PM, Daniel Zwolenski zon...@gmail.com wrote: There are definitely credible alternatives. The problem is currently the alternatives are not implemented well enough so web still ends up a contender just by being the only one able to stand up. And for the record I build both public facing apps and back-office apps and web deploy does not work well for either. I stopped using jfx because of deployment. I now build only webapps because of deployment. Credible alternatives: 1. Native bundlers, but we need: - auto updating so people can easily release patch updates - smaller co-bundled jre's so that the initial download and install is smooth and quick - better build tools to make this easier to integrate into a standard build process, with some solution for cross-platform build support or to at least minimize the pain 2. App stores: - ready to go right now for Mac but we don't have the tools and I think we need everything fully open sourced for licensing reasons (hard to say) - need to either pick one of the unofficial win app stores for pre-win8 support (there's a few), or build our own app store - we just need tools for building and deploying to app stores (not that hard) and cut down jre sizes again (app stores are an extension of cobundling approach). 3. Self-hosted 'app store' for corporate settings. install a small, native client on the machine that allows that user to download and install apps from your private server, with auto-updating, etc - we need to build one, not that hard, maybe a month or two of work to get a first working version out. I would have built one by now but because jfx packaging tools are so bad I've burnt up all my spare time just putting wrappers around these to get the most basic of maven plugins to work. All of the above could have been implemented by now if there was just a little bit of love in this area. One resource ticking away would have been enough to get something going. As it stands there has been zero, nada, zip changes into anything other than web/security deployment efforts over the last year. J8 due next year (!) will not include any of the above, or even any simple improvements to deployment approaches other than web, to the best of my knowledge. On 19/07/2013, at 7:30 AM, Mark Fortner phidia...@gmail.com wrote: I've heard the webstart is broke, don't fix it, move on song before from a number of people. What I haven't heard is a credible solution to solving the very real problem of keeping an app up-to-date in a corporate setting. For the most part, I agree that if you're in the business of selling commercial software, selling and distributing through an app store probably makes sense for you. Although I wouldn't relish having to build on all of those platforms. However, posting proprietary apps to external OS-specific app stores doesn't really work for anyone in a corporate setting. Neither does making a user re-install an application every time you post a bug fix. In addition, many corporations limit the privileges they give users. Cheers, Mark
Re: Java Deployment (was Re: JavaFX 8 Progress)
For Swing you can actually use CacioWeb, works quite well. Zero deployment, no VM needed, no plugin, just an HTML 5 capable browser. Doesn't work with JavaFX unfortunately. Cheers, Mario Il giorno 19/lug/2013 00:03, Daniel Zwolenski zon...@gmail.com ha scritto: There are definitely credible alternatives. The problem is currently the alternatives are not implemented well enough so web still ends up a contender just by being the only one able to stand up. And for the record I build both public facing apps and back-office apps and web deploy does not work well for either. I stopped using jfx because of deployment. I now build only webapps because of deployment. Credible alternatives: 1. Native bundlers, but we need: - auto updating so people can easily release patch updates - smaller co-bundled jre's so that the initial download and install is smooth and quick - better build tools to make this easier to integrate into a standard build process, with some solution for cross-platform build support or to at least minimize the pain 2. App stores: - ready to go right now for Mac but we don't have the tools and I think we need everything fully open sourced for licensing reasons (hard to say) - need to either pick one of the unofficial win app stores for pre-win8 support (there's a few), or build our own app store - we just need tools for building and deploying to app stores (not that hard) and cut down jre sizes again (app stores are an extension of cobundling approach). 3. Self-hosted 'app store' for corporate settings. install a small, native client on the machine that allows that user to download and install apps from your private server, with auto-updating, etc - we need to build one, not that hard, maybe a month or two of work to get a first working version out. I would have built one by now but because jfx packaging tools are so bad I've burnt up all my spare time just putting wrappers around these to get the most basic of maven plugins to work. All of the above could have been implemented by now if there was just a little bit of love in this area. One resource ticking away would have been enough to get something going. As it stands there has been zero, nada, zip changes into anything other than web/security deployment efforts over the last year. J8 due next year (!) will not include any of the above, or even any simple improvements to deployment approaches other than web, to the best of my knowledge. On 19/07/2013, at 7:30 AM, Mark Fortner phidia...@gmail.com wrote: I've heard the webstart is broke, don't fix it, move on song before from a number of people. What I haven't heard is a credible solution to solving the very real problem of keeping an app up-to-date in a corporate setting. For the most part, I agree that if you're in the business of selling commercial software, selling and distributing through an app store probably makes sense for you. Although I wouldn't relish having to build on all of those platforms. However, posting proprietary apps to external OS-specific app stores doesn't really work for anyone in a corporate setting. Neither does making a user re-install an application every time you post a bug fix. In addition, many corporations limit the privileges they give users. Cheers, Mark
RE: Java Deployment (was Re: JavaFX 8 Progress)
auto updating so people can easily release patch updates Checkout getdown = http://code.google.com/p/getdown/. It's simple, proven open source tech used to distribute the Puzzle Pirates MMORPG which had 4 million accounts and 250 million hours of play time in 2008. Forking getdown, swapping out its existing thin Swing UI and replacing it with a configurable JavaFX UI is likely a pretty easy process. Some additional work would need to be done to integrate it into modern build/deploy tool chains such as the javafx maven and gradle plugins. I think it makes sense for the native bundling option where the combination of the two allows (IMO) a reasonable replacement for webstart. Replacing applets is more difficult, you probably want to use something like CacioWeb or have cloud based logic and some rendering with a streaming protocol to the browser and final rendering inside an html5 canvas, but that kind of technology does not exist for JavaFX as far as I know. John -Original Message- From: openjfx-dev-boun...@openjdk.java.net [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Mario Torre Sent: Thursday, July 18, 2013 3:10 PM To: Daniel Zwolenski Cc: mike.ehrenberg@barchart.comEhrenberg; openjfx-dev@openjdk.java.net; JeremyJongsma Subject: Re: Java Deployment (was Re: JavaFX 8 Progress) For Swing you can actually use CacioWeb, works quite well. Zero deployment, no VM needed, no plugin, just an HTML 5 capable browser. Doesn't work with JavaFX unfortunately. Cheers, Mario Il giorno 19/lug/2013 00:03, Daniel Zwolenski zon...@gmail.com ha scritto: There are definitely credible alternatives. The problem is currently the alternatives are not implemented well enough so web still ends up a contender just by being the only one able to stand up. And for the record I build both public facing apps and back-office apps and web deploy does not work well for either. I stopped using jfx because of deployment. I now build only webapps because of deployment. Credible alternatives: 1. Native bundlers, but we need: - auto updating so people can easily release patch updates - smaller co-bundled jre's so that the initial download and install is smooth and quick - better build tools to make this easier to integrate into a standard build process, with some solution for cross-platform build support or to at least minimize the pain 2. App stores: - ready to go right now for Mac but we don't have the tools and I think we need everything fully open sourced for licensing reasons (hard to say) - need to either pick one of the unofficial win app stores for pre-win8 support (there's a few), or build our own app store - we just need tools for building and deploying to app stores (not that hard) and cut down jre sizes again (app stores are an extension of cobundling approach). 3. Self-hosted 'app store' for corporate settings. install a small, native client on the machine that allows that user to download and install apps from your private server, with auto-updating, etc - we need to build one, not that hard, maybe a month or two of work to get a first working version out. I would have built one by now but because jfx packaging tools are so bad I've burnt up all my spare time just putting wrappers around these to get the most basic of maven plugins to work. All of the above could have been implemented by now if there was just a little bit of love in this area. One resource ticking away would have been enough to get something going. As it stands there has been zero, nada, zip changes into anything other than web/security deployment efforts over the last year. J8 due next year (!) will not include any of the above, or even any simple improvements to deployment approaches other than web, to the best of my knowledge. On 19/07/2013, at 7:30 AM, Mark Fortner phidia...@gmail.com wrote: I've heard the webstart is broke, don't fix it, move on song before from a number of people. What I haven't heard is a credible solution to solving the very real problem of keeping an app up-to-date in a corporate setting. For the most part, I agree that if you're in the business of selling commercial software, selling and distributing through an app store probably makes sense for you. Although I wouldn't relish having to build on all of those platforms. However, posting proprietary apps to external OS-specific app stores doesn't really work for anyone in a corporate setting. Neither does making a user re-install an application every time you post a bug fix. In addition, many corporations limit the privileges they give users. Cheers, Mark
Re: Java Deployment (was Re: JavaFX 8 Progress)
A list of JWrapper's features: Oracle, are you ready to buy these guys yet? If you don't, we will… :) Easily deploy Java as native apps (for free) But lets break that down... Easily... To us, this means being able to build for everything, on anything - true cross platform builds. Multiple developers can share one build file, yet everyone can build for every OS. Users can get hold of your app and updates no matter what web server or scripting language you use. You issue a new automatically updated release by overwriting some files on your web server, and if we do our best to ensure your app has a predictable, stable environment. If use a system JRE we even copy it so you aren't exposed when Oracle decides to update it and break API. …deploy Java... To us, this means creating signed, iconified, automatically updating OS-native apps that can pick up a system JRE, download or bundle a heavily compressed one. Since we're replacing applets it also means making your app available on your website by just sharing the files and adding one line of HTML to embed a JavaScript download button. It also means stuff like automatically detecting HTTP proxies from wherever makes the OS has that info (system settings, browser settings) so that you don't have to guess at them yourself or hope that the system JRE is set up to use the right one (if there even is one). …as native apps To us this means it looks and feels like a native app. On Windows this means a signed executable which can elevate as you need. On OSX this means a signed .app file inside a DMG. On Linux this means a native exe inside a double-click extractable tar.
