Java Deployment (was Re: JavaFX 8 Progress)

[Daniel Zwolenski]

Interesting, though this still requires an initial install of a jre which is the source of half the problems in my mind. 

If this was put inside a native wrapper with a co-bundled jre then it is not a bad option. Basically this could be the start of the client for the build-our-own-app-store approach I listed in the viable options. Good reference to have. 

Really, the problem here though is not so much finding the solutions as having time to build them. I think most of us in the community see this as Oracle's domain, especially as they have a deployment team. In reality though, no one is actually working on these modern solutions because the deployment team is stuck constantly patching and fiddling with old, dying web deployment code that should be euthenasied. 

As an aside, it's worth pointing out that installing the jre now is worse than it used to be because of the forced auto updating and security related complexities that have been introduced in response to the security holes that were exploited in java. The addition of 64bit versions also have complicated the windows install, and made the web plugin get confused for some browsers. So webstart used to be a half-ok, just-bearable option but now it is utterly horrible and risky - just something to be aware of when considering other 'success stories'. 


On 19/07/2013, at 8:43 AM, John Smith <John_Smith at symantec.com> wrote:

>> 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-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Mario Torre
> Sent: Thursday, July 18, 2013 3:10 PM
> To: Daniel Zwolenski
> Cc: mike.ehrenberg at barchart.comEhrenberg; openjfx-dev at 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" <zonski at 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 <phidias51 at 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
>>> 
>>>