Petition to Open Source JavaFX

[Stephen Chin]

I put together a petition to encourage Oracle to open source JavaFX. It
is not a meant as an attack against Oracle, but instead a way to improve
the success of the JavaFX Platform.

Even if you are not currently using JavaFX, please consider reading and
signing the petition. The plan is to present this to the Oracle
leadership team during JavaOne 2010.
http://steveonjava.com/javafx-petition/

Cheers,
--
--Steve
blog: http://steveonjava.com/

[Carl Jokl]

I have signed.

While we are on the subject of JavaFX, is there any indication of when
the first real JavaFX phones will be available? It has implications
for an open source JavaME project I am working on. The application is
fairly complex and it may be difficult to keep the mobile jar size
within the permitted constraints for modern mobile phones. For this
reason I would be loathed to have to add the JavaFX runtime to the
distribution as there is a danger it would bloat the app to much and
push it over the limit.

I really worry that with all the attention that Android is getting
from Handset manufacturers it may discourage them from embracing
JavaFX Mobile. When JavaFX Mobile launched though there were several
companies listed as being committed to doing something with it.

In the case of my app I have a legitimate use for it (and am not just
using it for the sake of it). In my case there is a desire to try and
keep the UI of the app consistent with the iPhone and Android apps
already out (so that they feel like the same app as much as possible).
Obviously this is a lot easier to achieve with a GUI framework like
JavaFX Mobile than trying to code it myself.

[Fabrizio Giudici]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 7/16/10 12:14 , Carl Jokl wrote:
> I have signed.
Me too. After reading Kirill's post I knew that a post from Stephen
was in progress :-)

>
> While we are on the subject of JavaFX, is there any indication of
> when the first real JavaFX phones will be available? It has
> implications for an open source JavaME project I am working on. The
> application is fairly complex and it may be difficult to keep the
> mobile jar size within the permitted constraints for modern mobile
> phones. For this reason I would be loathed to have to add the
> JavaFX runtime to the distribution as there is a danger it would
> bloat the app to much and push it over the limit.
>
> I really worry that with all the attention that Android is getting
> from Handset manufacturers it may discourage them from embracing
> JavaFX Mobile. When JavaFX Mobile launched though there were
> several companies listed as being committed to doing something with
> it.

For Mobile JavaFX, I'm very pessimistic. I used it the past year for
implementing an idea I had in mind, thinking that many enabled phones
would have been made available. In the end, I waited for several
months for users' feedback, that didn't come (almost nobody has got a
JavaFX enabled phone, and furthermore the process of installing the
runtime isn't user oriented). I moved to Android a few months ago and
now my app has experienced a successful start, including some user
feedback. BTW, while my project is not commercial, nor is meant to
make money, I've realized that had I started with Android one year
ago, I'd have enjoyed one year without any kind of competition
(similar commercial applications for Android started to come out just
when I published my first releases). You figure out what this means.

So, if your app is related to some business, or in any case it will
experience some competition, I think you'd better to move to Android
(I mean, adding an Android port) rather than waiting further for
JavaFX. After the JavaOne I'll consider JavaFX Mobile definitely dead,
but even though some announcement is made (unless it's very big e.g.
Nokia says it will integrate it on all of its phones) it will be in
such a delay that it won't be able to compete with Android. In any
case, Android on mobile phones will be for sure in our future, and I
consider it an investment, in addition to supporting for the currently
huge base of JME phones.

- --
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
java.net/blog/fabriziogiudici - www.tidalwave.it/people
Fabrizio...@tidalwave.it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxAQWkACgkQeDweFqgUGxcXewCfY/NZGfI8z0SfIxHS4wov6lhZ
HbUAn3fiDejY6U6XkLDSj9/ELHQeorFr
=BuKq
-----END PGP SIGNATURE-----

[Carl Jokl]

In my case the same app is being developed for several different
platforms.
iPhone and Android already have released versions. Windows Mobile is
close
as is Web O/S. Blackberry is under development. I am currently the
JavaME team.

I don't need to move to Android because an application is already
released for that
platform.

Either the JavaME version will be released or it won't but currently
JavaME offers a
way to reach a whole bunch of phones which cannot be reached any other
way
(short of developing for them specifically using C).

Even in the current situation there is still substantial interest in
the JavaME version
because JavaME is still so prevalent in the developing world. There
may be a lot
of competition when it comes to smart phones but a lot of people just
have feature
phones. I am targeting these people. I am not expecting to offer the
same features
as the iPhone or Android versions of the app because that is
unrealistic on a more
constrained device. For these phones it is a JavaME app or nothing at
all.

JavaFX mobile would be an option of more powerful JavaME devices but I
still would not
be able to use it on lower end devices and so was hoping to create two
versions using the
same back end but different UI.

Beside my Laptop sits my HTC TouchPro 2 with the JavaFX preview SDK
installed. I expect
I will probably get myself an Android phone for Christmas.

[Fabrizio Giudici]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 7/16/10 13:35 , Carl Jokl wrote:
> In my case the same app is being developed for several different
> platforms. iPhone and Android already have released versions.
> Windows Mobile is close as is Web O/S. Blackberry is under
> development. I am currently the JavaME team.

Ok, now your scenario is clear. Drifting a bit the topic, what
approach did you use for supporting, say, JME and Android? Two
complete re-writes or are you able to reuse something? I have to
support them both and I'm experimenting a bit.

- --
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
java.net/blog/fabriziogiudici - www.tidalwave.it/people
Fabrizio...@tidalwave.it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxAUzAACgkQeDweFqgUGxfTBgCdG6EfbONE358AXgFgDKboNOhi
jo4AoKTlg0K4/Nh42AyTafsbXM18jzib
=xd8k
-----END PGP SIGNATURE-----

[Carl Jokl]

In the case of the apps being created, each application team is a
group of unpaid volunteers. The teams are essentially self contained
and the applications are developed independently of each other.
However if someone in one team has an approach or a tool that can help
out another team out. At this stage there isn't so much code sharing
going on that I am aware of. In the case of the JavaME app. I cannot
really do things the way I know the other apps work because the
constraints for JavaME are a lot tighter i.e. I have less memory and
storage and fewer built in libraries and API's. This means for example
where both the iPhone and Android app use rendering of HTML for
example It isn't really practical for my JavaME app to do this due to
constraints to both app size and memory. This leaves me doing low
level drawing. This doesn't bother me though because I like pain.
JavaME for me is like being back in the 80's except this time i'm
awesome.

[jitesh dundas]

+1

I have signed too.Good move..

Thanks,
jd

[opinali]

I've signed the petition too, although I don't think this will have
any immediate impact. I just hope Oracle is listening - virtually 100%
of the prominent outsider JavaFX enthusiasts have signed it. But even
if Oracle is already planning to open FX, they will most certainly
wait to announce that at J1'10 when they can make a huge PR splash
about it.

I agree that this JavaOne will be decisive for JavaFX. The already-
sure thing is that JavaFX TV will ship soon - v1.3.1 is expected to
bring a production-quality port for the Intel CE 3100/4100 platform. I
guess we'll be able to buy some HDTV sets with FX next Christmas. But
oddly enough, the roadmap is much less clear for the JavaFX Mobile
profile, that should have hit the market much sooner. It seems Oracle
had to rethink their strategy when MS announced that WinMob7 won't be
very friendly to native apps - although frankly, this may not be very
relevant, because any user-installable FXMob runtime (even OTA) will
not cut it; the only chance for FXMob is shipping OEM, which requires
some buy-in from device makers. (I don't know if WinMob7's licensing
rules will allow OEMs to integrate third-party platforms like FX, but
I suppose that would be possible.)

The FX team seems to have used this opportunity to make some important
improvements in FX's multi-platform approach. The original concept of
profile was substantially improved, with a capabilities API to
dynamically query the runtime for optional features, and stubs that
allow unsupported classes (like the Effects) to exist, but degrade
gracefully, in lower profiles. Add to that the fact that the TV
profile is virtually identical to Desktop (and Prism-only), and
JavaFX's multiplatform story seems like something designed in heaven,
especially compared to its competition. I suppose also that they've
been working ahead on performance and other issues, ever since the 1.2
release. But time's up; endless implementation improvements won't do
much good if FXMob doesn't start shipping soon. The window of
opportunity still exists but it's closing quickly, as more mobile-RIA
competitors like Flash 10.1 and Silverlight start shipping.

The Java Store is another important piece of the limbo where FXMob has
entered this year. The beta Store is apparently dead, and I think
Oracle must be reevaluating it from a broader strategic perspective.
Maybe they will kill the store (or keep it only for other profiles),
if this makes easier e.g. to arrange deals so Android handsets will
have the FXMob runtime and the Android app store will allow users to
buy and install FXMob apps; same for Nokia handsets with Ovi, etc.
This is just a wild guess, but the app stores issue is certainly part
of the problem, and part of whatever new roadmap that Oracle has been
working on lately (and hopefully, we will get to know in Sept 19...).

A+
Osvaldo

On 16 jul, 08:24, Fabrizio Giudici <fabrizio.giud...@tidalwave.it>
wrote:

> Fabrizio.Giud...@tidalwave.it

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.14 (Darwin)

> Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/

[jitesh dundas]

To be honest, Oracle is going to customize this framework and use it for competing with MS. Plain and simple.

You will see some new App Server or a compiled package coming up with Java a part of it or java being tuned up to suite Oracle suite of products..Nothing new in its strategy.

Regards,
jd

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Mash]

I signed the petition. JavaFX is at a critical juncture in my view,
despite the hype surrounding it for the past two years it really
hasn't made any headway, and there are now signs of early adopters and
enthusiasts giving up and deserting it. I think unless an
announcement of significant investment and/or a plan to open source
comes at JavaOne, or even an impressive app, it will really be too
late.

That would be a shame because I think that there is a niche for the
technology - not directly as a Flash/Flex/Android competitor, but more
perhaps as a lightweight Swing alternative. In this case, the main
developer community would be those who are already using the
technology - existing Java developers, and not so much Designers. If
you could easily put a decent GUI on top of an existing Java
enterprise application, then this is an area where it has potential.
Open sourcing is the obvious way forward IMO.

LoadUI (http://www.loadui.org/loadUI-Demo-Movies.html) is an example
of what can be done with JavaFX.

On Jul 16, 10:34 am, Stephen Chin <st...@widgetfx.org> wrote:
> I put together a petition to encourage Oracle to open source JavaFX.  It
> is not a meant as an attack against Oracle, but instead a way to improve
> the success of the JavaFX Platform.
>
> Even if you are not currently using JavaFX, please consider reading and
> signing the petition.  The plan is to present this to the Oracle

> leadership team during JavaOne 2010.http://steveonjava.com/javafx-petition/

>
> Cheers,
> --
> --Steve
> blog:http://steveonjava.com/
>

>  smime.p7s
> 8KViewDownload

[Casper Bang]

As I've said before, the only way to revive the still-born project
JavaFX is if Oracle delivers a stack on top of Android. Since it
doesn't seem like this is in the plan, I hope it will die soon so
resources can be released to other stuff. Just too bad we had to loose
so many luminaries over it (Hans Muller etc.)

[jitesh dundas]

Do you think that would be profitable for Oracle in the long run.>maybe yes, but I would like to valuidate that..

JD

[opinali]

Statements like "JavaFX is still-born..." (without any qualification)
are always problematic... remembers me of Kirill Grouchnikov's recent
blog where he complains that JavaFX's support for designers still
sucks (true), but uses that to conclude, remarkably in the attention-
catching title, that JavaFX (unqualified: as a whole) is already a
"train wreck". This is a classic fallacy of using a single valid
argument to "prove" some conclusion that has much broader scope and
would certainly have said argument as necessary, but not sufficient.
Kirill soon closed the blog for comments because the discussion
deviated to "not relevant" issues like "licensing, J2me, swing et al".
Well, all these issues are relevant if one tries to declare the fate
of JavaFX as a whole. Just like JavaFX can be successful enough
without a CS5-class designer support (unnecessary, say, to displace
Swing which doesn't have that either), JavaFX can also be successful
enough without any mobile support (unnecessary, again, to displace
Swing). Of course, both the integration of traditional GUIs with
modern RIA features, and the smooth support for several platform
classes including mobile, are important strengths of the overall
JavaFX proposition... if Oracle executes well on the full plan, JavaFX
will be difficult to stop in any of these roles. But supposing that
this doesn't happen, but they still deliver a great toolkit for
traditional GUIs (that are "mostly coded" and not "mostly designed"),
and only for desktops, that's still a hell of a huge market, big
enough to call JavaFX successful if it bits a decent chunk of that
market.

A+
Osvaldo

[Casper Bang]

You offer a lot of "can be", "if" and "supposing", which is no more
qualified than what you are arguing against. As none of us can predict
the future, here are a few observations behind my reasoning:

On the web:
The roll-out and delivery does indeed look like a train-wreck, and by
the time the train builds any substantial momentum, the browser plugin
model will have run it's course. It's almost as if Sun failed to see
the bad data-points they extrapolated from; Applet's a la 96' was not
a success and Adobe Flash/Flex mainly worked due to Flash being a
video catalyst (and is slowly but surely coming apart now thanks to
Apple especially).

On mobiles:
For unknown reasons, JavaFX (and Sun in general) completely missed the
boat on mobile which is slated to become as huge as desktop computing
currently is. Since Android development is still pretty hard-core and
mostly a fresh start (a new way of doing things and a new language
subset), this is where JavaFX had a window-of-opportunity... so it was
sad to see Sun not taking advantage of this. I can only guess they did
not want to embrace Android for dogmatic rather than pragmatic
reasons, as seen before by Sun.

As a Swing replacement:
Last but not least, as a pure Swing replacement... that assumes Swing
was popular to begin with, even if on sourceforge you can probably
find a ratio of 100:1 between Java Web Frameworks and Java Swing
applications. You can do a lot with Swing, but it never realized the
pipe-dream set forth by it's mission statement. You go and download
Picasa, Google Earth or a similar pervasive application and it's still
not written in Swing.

Target community:
It's hard to find people outside the Java community who have heard,
let along cares, about JavaFX; which you need to contrast with similar
stacks i.e. Microsoft's WPF/XAML or Adobe's Flex/Air. Sun kept the
name JavaFX, drawing in people already loving Java but also making
people run screaming away due to past painful experiences with Java/
applets. Also unique to JavaFX, is a whole new syntax shaping the
learning curve considerably. As someone who actually like the succinct
syntax and the embracing of hierachies, it's a darn shame JavaFX got
such a narrow applet 2.0 focus rather than being pushed as a general
purpose Java .Next.

Prospect:
If Oracle executes swiftly and tries to solve actual problems, rather
than taking up the torch from Sun and producing pretty but ultimately
useless JavaOne JavaFX demo's, then good. But at this point in time,
it seems that the arguments against outweigh the arguments for.

/Casper

[Carl Jokl]

There is a definite move away from plugin technology or at least
momentum to do so. Perhaps there is a degree of polarisation on the
issue.
I could point out that Microsoft is currently going down the plugin
route with Silverlight and so it is not as if JavaFX is the only one
trying to
push a plugin based solution.

There seems to be an attitude from many that HTML 5 is going to fix
everything. I find it almost amusing when browsers claim to be HTML 5
compliant
given the standard is not even close to being finalised. How can a
browser be compliant with an unfinished standard which may be subject
to change?

I feel I have earned the right to a bit of scepticism about new
standards. How did the transition to XHTML go? Oh wait, IE after 10
years hasn't got around
to properly supporting it so it kind of fell by the wayside. How is
ECMA script doing at standardising JavaScript behaviour? I still see
plenty of JavaScript
having to feature probe or have conditional code.

The browser inconsistency is somewhat better than it was but still
very much exists even today. Anyone who has wasted time dealing with
some browser inconsistency knows it is not fun to spend time
compensating for things which should be taken for granted to just
work.

How fun is it to build complex applications in JavaScript? JavaScript
2 was going to beef up the language to better cope with this kind of
stuff but Microsoft essentially vetoed the changes and it fell by the
wayside to be replaced with less ambitious changes. The justification
was that if you needed that kind of heavy lifting then a plugin
technology would be better. Now we talk about doing away with the
plugins.

In an ideal world HTML 5 isn't a bad idea or principle. The problem is
that in practice these movements always end in fragmentation. Usually
with IE falling the furthest outside the standards which the rest of
the browsers are trying hard to comply with. Do I expect this to
change for the foreseeable future?

In the mean time plugins provide not only a very consistent platform
and experience but also use languages more robust than JavaScript. The
development experience is smoother all in all.

Maybe I am a fool to believe that Applets really could still be
awesome with some work. I know that they have unfortunately have a bad
name due to bad experiences in the past.

[Fabrizio Giudici]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 7/20/10 10:49 , Casper Bang wrote:
>
>
> On mobiles:
> For unknown reasons, JavaFX (and Sun in general) completely missed the
> boat on mobile which is slated to become as huge as desktop computing
> currently is. Since Android development is still pretty hard-core and
> mostly a fresh start (a new way of doing things and a new language
> subset), this is where JavaFX had a window-of-opportunity... so it was
> sad to see Sun not taking advantage of this. I can only guess they did
> not want to embrace Android for dogmatic rather than pragmatic
> reasons, as seen before by Sun.

Agreed, with two more points:

1. In the past Sun said they did have a JavaFX port on Android, but
Google didn't like it and didn't want to see it. We're talking of a
direct port of JavaFX with all its widgets and I understand why Google
doesn't like it (I don't understand why a company that pretends to be
open and "not evil" raises vetoes, but this is another story). In the
end, at this point it wouldn't be a good idea, probably. As it has
been already said, what could be useful is a JavaFX port _with the
Android runtime and widgets_. Of course, you loose the original idea
of portability of JavaFX (but given that there is almost zero other
devices running it, there's no real portability issue). But you could
use the good parts of the language to compile Android code.

2. I understand that there could have been some dogmatic reason in Sun
not to re-purpose JavaFX Mobile in this way, but the Oracle takeover
should be profitably used as a breaking event, when you take the
advantage of looking at things as you didn't in the past...

- --
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
java.net/blog/fabriziogiudici - www.tidalwave.it/people

Fabrizio...@tidalwave.it

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxFfJgACgkQeDweFqgUGxdOdACghIf/QvypbC5ZyU8js8beO0Sd
OTUAn0BaTSOhMLxYHzYpGeD94mi77gdi
=h+x5
-----END PGP SIGNATURE-----

[opinali]

On 20 jul, 05:49, Casper Bang <casper.b...@gmail.com> wrote:
> You offer a lot of "can be", "if" and "supposing", which is no more
> qualified than what you are arguing against. As none of us can predict

That's true, but at least I'm clear about my suppositions.

> On the web:
> The roll-out and delivery does indeed look like a train-wreck, and by
> the time the train builds any substantial momentum, the browser plugin
> model will have run it's course. It's almost as if Sun failed to see
> the bad data-points they extrapolated from; Applet's a la 96' was not
> a success and Adobe Flash/Flex mainly worked due to Flash being a
> video catalyst (and is slowly but surely coming apart now thanks to
> Apple especially).

I don't see a big problem with the plug-in model. Yeah it's certainly
not trendy, but Java[FX] is not alone betting the farm on it - along
with Flash there's also Silverlight and Google's PNaCl, just to name
the big guys. And your report of Flash's demise is exaggerated. Some
time ago, due to an ArsTechnica pledge against ad blocking (that kills
the revenue stream of great sites like Ars), I've disabled my AdBlock
and decided to use FlashBlock instead - because it's too much work to
maintain a personal ad whitelist for all sites I care about; so I
thought FlashBlock would be a better replacement: see all ads,
blocking only the most pesky, Flash-based ones. I've endured the
experience for a few months, but finally desisted... because there are
way too many sites making good (or at least, not too bad) use of
Flash, for navigation and presentation.

I know that most of such uses can be replaced by new HTML5/JS code,
but this will take a LONG time to happen; maybe not in high-profile
sites, but certainly so in the other 99% of the web - sites that are
maintained once in a blue moon, like your local grocery store with a
delivery website that was put together by some "web designer" back in
2006. Clicking FlashBlock's 'play' icon is no fun when you reach a
page that has half-dozen of them - and when you do that, you must do
it at every new visit to the page... and then the Flash objects often
fail to work correctly, perhaps due to missing onload events or init
order, whatever... Maybe a smarter FlashBlock would fix all that, but
for the time being I've just desisted - back to AdBlock, with the very
short whitelist that I had the patience to fill. YMMV, maybe I'm just
too lazy. The simple fact though, is: there's GOBS of Flash in the web
and it's not just the video players soon to be killed by <video>.

As for the Java plugin, yes it does have problems, but the important
problems are not related to the plugin model. The JRE's installation,
update and loading-time experience still has a long way to improve.
JAWS is ugly, JNLP files are shit. Applets may have scrolling and
refresh bugs inside the browser. Security is still more intrusive than
it could be. Ditto for Java branding, we don't need those stupid logos
and trademarks at every app launch, the Java runtime should be
invisible like Flash is. These things must be enhanced or fixed.

> As a Swing replacement:
> Last but not least, as a pure Swing replacement... that assumes Swing
> was popular to begin with, even if on sourceforge you can probably
> find a ratio of 100:1 between Java Web Frameworks and Java Swing
> applications. You can do a lot with Swing, but it never realized the
> pipe-dream set forth by it's mission statement. You go and download
> Picasa, Google Earth or a similar pervasive application and it's still
> not written in Swing.

I agree, I didn't claim that Swing was a wild success, at least not in
the Internet - it's at least a bit more successful for corporate apps.
And in the role of Swing Killer, JavaFX is not a 1-to-1 replacement;
it's a superior replacement (OK, it _plans_ to be - right now there
are some important missing pieces). The idea is to capture whatever
market that Swing has today, and build from that point.

"Big" apps like Google Earth are very bad examples. Most GUIs out
there don't have the kind of resources of the Google Earth project,
not even for a single platform. Java+Swing (or Java+SWT and other
variants) is way more productive and cheap to develop than anything
that I know, remarkably toolkits based on C/C++. I can see other
toolkits of similar (high) level to match or beat Java's productivity
and ROI, e.g. Mono with Gtk#. But then they're in the same ballpark of
Java[FX]. Of course, traditional toolkits will always have an
advantage in platform-specific power, loading time, resource usage.
It's a case-by case balance. My favorite SQL client is Oracle's
SQLDeveloper, that is written in Java and a bit bloated (besides
written in Java, it's a custom build of JDeveloper, so it carries some
IDE infrastructure that wouldn't exist in a more custom-made app)...
there are several, good native options like TOAD etc, but I really
love SQLDeveloper. But my text editor is the native Notepad++, because
I open text files one million times per day, often to load enormous
application log files, so loading time and raw speed and efficient
resource usage are everything for me, no Java editor can compete.

> Target community:
> It's hard to find people outside the Java community who have heard,
> let along cares, about JavaFX; which you need to contrast with similar
> stacks i.e. Microsoft's WPF/XAML or Adobe's Flex/Air. Sun kept the
> name JavaFX, drawing in people already loving Java but also making
> people run screaming away due to past painful experiences with Java/
> applets. Also unique to JavaFX, is a whole new syntax shaping the
> learning curve considerably. As someone who actually like the succinct
> syntax and the embracing of hierachies, it's a darn shame JavaFX got
> such a narrow applet 2.0 focus rather than being pushed as a general
> purpose Java .Next.

IMHO the learning curve is very smooth, remarkably for the JavaFX
Script language, but it's difficult to judge these things for the
"common programmer". I agree that the language could and should be
more ambitious; see my blog "JavaFX Script as a general purpose
language?": http://weblogs.java.net/blog/opinali/archive/2009/06/javafx_script_a.html.

> Prospect:
> If Oracle executes swiftly and tries to solve actual problems, rather
> than taking up the torch from Sun and producing pretty but ultimately
> useless JavaOne JavaFX demo's, then good. But at this point in time,
> it seems that the arguments against outweigh the arguments for.

Mostly agreed. FX certainly has yet to cross the chasm, I think even
most enthusiasts agree. But I just think that it's early to call fail.

A+
Osvaldo

[opinali]

I've saved the Android part to answer here, building on Fabrizio's
reply. My $2c: The most obvious problem of a JavaFX/Android port is of
course the base platform. Should it run atop Dalvik and its core APIs,
or carry together a full JavaME VM? Both options have some
complications and tradeoffs.

1) JavaFX on Dalvik: Allows people to write Android-specific FX apps,
that reach into Google's APIs. This is of course both good and bad.
It's probably even necessary to have some integration to Android's
APIs, e.g. Intents/Activities, to enable "first-class" apps. The
performance of the Dalvik VM is probably no big deal now that it has a
JIT, and also considering that JavaFX (remarkably its Mobile profile)
relies heavily on native code.

2) JavaFX on JavaME: Carries a very big dependency into the Android
platform, and will make any kind of system integration very difficult
at best. But it would allow execution of unpure JavaFX Mobile apps,
that reach into the underlying ME APIs when there's some gap in the FX
APIs (and this will probably be common for some time to come). Would
the base JavaME VM support standard midlets too? These would be even
harder to fit in Android. Best technical solution is very likely a
custom base platform, using the core ME APIs, but only including
whatever FX needs and excluding the rest like LCDUI... but that would
create some bizarre Frankenstein, unless direct app access to any such
APIs is artificially forbidden (and then, you lose the advantage of
tunning unpure FX/ME apps).

My bet is that this initial FX-on-Android prototype was option 2
above, and I can easily see Google blocking FX for this reason alone,
without Google being "evil" or Sun being "dogmatic". This option is
clearly the worst, it's only good enough for a quick prototype. Option
1 is the least evil, and looking forward, e will be able to build pure
JavaFX Mobile apps that will also be great Android apps, in the future
as FX's native APIs expand to fill the gaps and to allow transparent
bridging to critical system-specific services. But the implementation
effort in this option is likely much bigger, even for that initial
prototype.

A+
Osvaldo

On 20 jul, 07:38, Fabrizio Giudici <fabrizio.giud...@tidalwave.it>
wrote:

> Fabrizio.Giud...@tidalwave.it

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.14 (Darwin)

> Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/