for once I believe Sun's marketing re a JavaFX competitve angle

[RogerV]

Folks in this forum know that I've been pretty much on the Adobe Flex
train - have overseen development of Flex software for a couple of
years now.

More lately am dealing with AIR development specifically.

Before the Flex development was very much now RIA web app focused.
However, now the emphasis is on desktop (AIR) with a hybrid RIA web
app approach (a portion is installed as AIR desktop app, but
significant portions still load as Flex forms from a web server).

As such am discovering some of the short-comings of AIR. The obvious
comparison point is the Java JRE.

The most obvious and most often complained about shortcoming of AIR is
that there is no API for launching other arbitrary apps in their own
process context. In our case we actually want to build a portal
program launcher in AIR. Yes, some of these will be URLs to web apps,
but some of them are also desktop apps.

Another is that even though AIR has File and FileStream classes for
interacting with local files, there does not appear to be any
provision for async interaction with stdin, stdout, or stderr. It
would be great to launch an AIR as a subprocess and to do interprocess
communication via just using stdin/stdout (I've written a zillion
powerful multi-processing perl applications along these lines).
Instead folks end up resorting to some agreed upon localhost port and
doing socket i/o. Doing a stdin/stdout between parent and child
processes would be much better, as would be performant and trouble
free from configuration and security standpoint.

There are several projects that have emerged that attempt to buck up
the deficiencies in AIR:

FluorineFx Aperture
Shu
Merapi

It's interesting that such a cottage industry has sprung up. The
Merapi project is a Java to AIR bridge. It actually does asyn
messaging between Java code and AIR code where they done some sort of
AMF implementation to marshal objects between Java and ActionScript3.

Turns out there's very keen interest in this kind of thing.

A lot of folks are very much sold on the Flex development model - it
is really nice, productive, and delivers great results in terms of the
GUI. Yet when you start working on the desktop - well, AIR tends to
leave a lot to be desired in terms of maturity. Those of us from the
Java world know things could be much richer. It would be great to
combine the strengths of both - hence solutions such as Merapi.

The obvious take-away for Sun here is that some of their marketing
message about the strengths of Java (inclusive of JavaFX) is that the
Java SE is indeed very mature and feature laden. So a word of advice
to Sun - start concentrating your marketing message for JavaFX in the
space that Adobe AIR is targeting. To do that though, they're going to
have to include something like Webkit in the Java SE so they can also
have a first rate HTML rendering solution (and a fast JavaScript
interpretor that's competitive to Google's V8).

Adobe needs to bolster AIR with more features while Sun needs to buck
up the web programming story of using HTML/JavaScript/DOM in
combination to JavaFX. So here is opportunity for some good old
fashion big vendor competition that seeks to win the hearts and minds
of developers.

[Steven Herod]

Wow, Merapi, seems to be the worst of both worlds. Deploying that is
likely to suck.

Webkit is coming to Java via the JWebPane component which I keep
hearing rumors about -
http://weblogs.java.net/blog/alex2d/archive/2008/12/jwebpane_projec.html

I agree with the rest of your points and add one more, if the 'All the
screens of your life' turns out to be true (phone, TV, set top box,
computer etc). It is going to be a powerful thing. Fingers crossed
on their ability to execute the vision.

[RogerV]

On Jan 26, 4:25 am, Steven Herod <steven.he...@gmail.com> wrote:
> Wow, Merapi, seems to be the worst of both worlds.   Deploying that is
> likely to suck.

Yeah, deploying a Java app and an AIR app together, that is then going
to do interprocess communication over a localhost socket so as to act
like a single application, is by no means ideal. Especially wouldn't
be great for consumer style applications. For enterprise, well, there
we can make an installer process that takes care of everything. In our
case we have to run Oracle Forms (which is implemented as a Java
applet) for legacy stuff anyway, so we're already stuck with having to
use Java. But in time that requirement will go away. And in time AIR
will add an API to launch other applications.

People doing stuff with USB, UDP, Java libraries like for the WII or
Lego Mindstorm robotics are finding Merapi useful.

And one particular capability that Merapi has that makes it somewhat
worthwhile is support for AMF marshaling of objects bi-directionally
between Java and ActionScript3.

The bottom line, though, is you're right - a bridge solution like
Merapi is a clumsy way to go.

[Karsten Silz]

On Jan 24, 9:51 pm, RogerV <rog...@qwest.net> wrote:
> [...]

> The most obvious and most often complained about shortcoming of AIR is
> that there is no API for launching other arbitrary apps in their own
> process context. In our case we actually want to build a portal
> program launcher in AIR. Yes, some of these will be URLs to web apps,
> but some of them are also desktop apps.

Looks like it may be on the roadmap for AIR 2.0:
http://www.flashmagazine.com/News/detail/air_roadmap/

Without any roadmap knowledge, my guess is that AIR 2.0 will coincide
with Flex 4.