Fwd: Re: No JavaFX for iOS, Android or WP - why not?

[Mark Fortner]

Hi Peter,

Comments below.


> 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
> you
> >    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
> "special"
> >    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.
>  Support
> >    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
> needs
> >    to be in place. The current examples only demonstrate how to put
> JavaFX
> >    components within Swing applications.  Unfortunately, if you want to
> reuse
> >    any existing components (like JFreeCharts for example) within your
> project,
> >    you're SOL at the moment.
>
> They is not going to be 100% free ride on this extra third party
> functionality.
>
> 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 want
>

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
> would
> >    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 distribution
>

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
> to
> > 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.


Mark