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 of
