No JavaFX for iOS, Android or WP - why not?
Claus.Luethje at osys.ch
Mon Oct 15 04:45:39 PDT 2012
+1 for the maven support
From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Mark Fortner
Sent: Mittwoch, 10. Oktober 2012 17:28
To: openjfx-dev at openjdk.java.net
Subject: Fwd: Re: No JavaFX for iOS, Android or WP - why not?
> I am preferring to use Gradle these days. Nevertheless the issue of
> putting JavaFX in a Maven Repository is an important. Because JavaFX
> is not pure Java, the problem with linking with native library is a
> major concern.
> Whatever JavaFX JAR you put in a artifact repository, whether SonaType
> or Artifactory there has to be way to guarantee the code in the JAR
> can always find the native libraries. Oracle have not come with a
> scheme. I do not know of a safe way to do this portably that is cross
> platform and work across all systems with causing a break if one or
> the other dependencies are upgraded. The version, the native library
> and the potential upgrades are the sticking problem.
> Then there is a licensing of the JavaFX Runtime and distribution of
> Oracle's implementation.
Agreed. The assumption seems to be that if you use the Ant tasks to build, then you're OK. Everything else, you're on your own. Most of the organizations I've worked for left Ant behind 10 years ago. A mojo version
of the Ant tasks would make deployment easier. A maven archetype for
creating JavaFX projects would go a long way to making things easier. You simply run the archetype all of your dependencies, Eclipse/NetBeans project files, runtime environment variables are created for you. You could even add a starter application.
> > - *Webstart deployment *- this is still problematic. Currently
> > when
> > push new artifacts to your web server, it's not replacing the
> existing JARs
> > in the user's cache -- despite what the documentation says. The
> > javafx tags aren't documented well enough and presume that you're
> using the
> > Ant tools to generate the JNLP. And getting shaded jars is next to
> > impossible.
> I do not have an answer to this web start problem. I do assume you can
> upgrade Java 7.
I'm currently running Java 7.
> > - *Charts* - support for zooming and panning within the charts.
> > for drawing on top of charts.
> The controls and charts code is open source, go and implement your
> chart component.
> Start with a copy of the line chart and hack it.
Not really looking to hack JavaFX classes to support basic functionality.
I figure if I can do zooming and panning in Google Charts in a web browser, then I should be able to do the same with JavaFX. BTW, I tried hacking LineChart, and then quickly realized I would also have to hack NumberAxis because some fool made it final. The scope of my hacking quickly started to grow so I stopped before it got out of hand.
> > - *Support for Swing components within JavaFX. * If the goal is to
> > replace Swing, then this is one of those essential capabilities
> > that
> > to be in place. The current examples only demonstrate how to put
> > components within Swing applications. Unfortunately, if you want
> > to
> > any existing components (like JFreeCharts for example) within
> > your
> > you're SOL at the moment.
> They is not going to be 100% free ride on this extra third party
> 1) Modify JFreeChart and port some of it or all of it to JavaFX
> 2) Hack the existing Chart package until it gets you 80/20 of what you
Unfortunately, if they're positioning this as a replacement for Swing, then they're going to need to have some way of support Swing components. There are just too many Swing libraries out there that may never get ported over.
If SWT can be supported, I don't see why Swing can't. Either the original owners don't want to port them, don't have the funds to do it (this is especially true with academic libraries used for scientific applications), or have abandoned the code base.
When you're contracting, porting a library is typically not part of the scope, since it's assumed that whatever components you're using already support 80% of what you want, and you just need to add functionality specific to the problem domain you're working in.
> > - *Support for an EventBus.* Currently, there's a lot of point2point
> > event code that you have to write to fire and listen to events.
> > It
> > make for a much more useable codebase if you could simply publish and
> > subscribe to events at the application level.
> Why not write a JavaFX extension framework that maps JavaFX Event to a
> MessageBus implementation.
I'm not saying I can't write this, I'm saying I shouldn't have to. The point2point event model breaks down after a while especially in a highly interactive application, and results in memory leaks when you can't or don't disengage your listeners.
> > - *Release the source.* It's a royal pain to have to download the
> > source through mercurial rather than simply read it as you do with the
> > Swing code or download it as you do with any Maven package.
> The source code is there as JavaFX 2.2 as openjfx already.
> I think you meant make the source code also a downloadable distribution.
Actually, since it currently ships with Java 7, the source code should be included just as the source code for Swing is included.
> Hack the build.xml in the openjfx project, and contribute the Ant target.
> I also note that there should be a standalone JavaFX Doc as
Usually these are part of the standard Maven build -- so if they built with Maven they would get that for free.
> Ditto - hack the build.xml to javadoc and zip up the javadoc
> Contrib the patch back to the team
> > There's also some work that needs to be done to make it easier for
> > people to participate. I have 3 accounts at the moment: one for
> > this mailing list, one for the forums, and one for JIRA. Can we
> > just boil that down
> > one, and let me login with Facebook or Google credentials?
> Have you heard of the online services Google Onepass or LastPass or
> Yahoo Super wallet?
Not really looking for an alternative, merely the ability to sign on without having to create new accounts everywhere. One of the goals of the JavaFX project (described in Richard's quarterly report) is to increase
community participation. Most of what I've mentioned are items that
should lower those barriers to entry.
More information about the openjfx-dev