On Feb 23, 6:06 pm, Joshua Marinacci <[email protected]> wrote:
> Hi Karsten. This is Josh from Sun.
Thank you for dropping in here!
> You are correct that JavaFX is not as mature as Flex and Sliverlight.
> This is simply because it is newer. When comparing JavaFX to these
> other toolsets please keep that in mind. JavaFX 1.0 was released only
> about 3 months ago. But we are working very hard to improve and expand
> JavaFX very quickly. We've already had one update release and another
> is planned for around the JavaOne timeframe.
Yes, JavaFX is new, and it is moving fast (it took two years to get
Flex right initially on the desktop, though it changed owners during
that time). But when you were asked in the podcast why Flex develoers
should look at JavaFX, you didn't say "Come back in half a year", you
said the power of the Java ecosystem is there. Now I'm just looking
at JavaFX. ;-)
> JavaFX's strengths: though JavaFX is behind Flex & Silverlight in
> several ways (notably designer tools and components), JavaFX has some
> distinct advantages over the competition.
>
> First, it is built on the powerful and mature JVM letting you drop
> down to Java code at any time. This means you get all of the great
> things the JVM provides for free. It is the fastest client technology
> available for compute intensive applications. It has robust multi-
> threaded computing support. And you can access the rich ecosystem of
> existing Java libraries out there (millions of lines of open source
> Java code).
As I already mentioned, a Flex app with a Java back-end has access to
the biggest part of the Java ecosystem (and all the other ecosystems
on the server). And JavaFX, Flex/Flash and Silverlight are all DSLs
for UIs, which means the VMs are reduced to render forms and tables in
a single GUI thread and maybe having a background thread for network I/
O, so the JavaVM loses most advantage overs the Flash Player (which
has been a "UI VM" for more than ten years now) or the Silverlight VM.
Now with JavaFX, you can call into "local Java" to do computation, but
that means you're competing against native apps or Swing apps, not
against Flex or Silverlight apps anymore (which by definition are UIs
to server-side logic). In enterprise Flex / Silverlight apps the
server logic needs to access enterprise systems & databases most of
the time, so even if you wanted to "ship some calculation to the
client", that wouldn't be practical in most cases because shipping the
data is much more expensive than doing the computation server-side.
Also, with apps going multi-client (web + mobile, maybe desktop),
putting code in for just one of your clients increases the complexity
of your app.
> Now I understand that talking to bluetooth isn't a compelling feature
> for your enterprise application. But what if you have validation code
> on your server. Why write that again in a different language on the
> client when you could just share the jars directly between client and
> server.
Sorry, bad example. Form validation is built into Flex in a
declarative way, so that's the easiest way for us and could be even
defined by designers:
<mx:EmailValidator id="emailValidator" source="{this.emailInput}"
property="text" required="true"/>
<mx:PhoneNumberValidator id="phoneValidator"
source="{this.phoneInput}" property="text" required="true"/>
<mx:StringValidator id="stateValidator" source="{this.stateInput}"
minLength="2" maxLength="2" property="text" required="true"/>
<mx:ZipCodeValidator id="zipcodeValidator"
source="{this.zipcodeInput}" property="text" required="true"/>
We have, and that's probably typical, more complex validations (such
as checking whether a MAC or IP address is unique), but they have to
run on the server because only the server has all the data. So I
don't think we t really have a need for sharing client and server-side
validation code.
> Webservices? Why write new webservices marshalling code when
> you can use the great SOAP, RMI, and REST apis which already exist.
Flex can call web services and REST and has native XML support. Now
as soon as we started sending some more data (like a couple of
thousand records) to our Flex client, we found that for us, only the
binary AMF3 protocol was fast enough.
> What if you need to recompute some charts using special scientific
> algorithms that are on your server. Just reuse it directly on the
> client. No rewriting is necessary.
This is certainly a set of applications that will benefit from JavaFX
where all the data you need is on the client or can be shipped there
easily. Again, there you compete against native apps / Swing, not Flex/
Silverlight. Now our app, like probably most enterprise apps, needs
to access enterprise data - which is on the server, and shipping this
data around is not practical, unless you're a grid / SETI app.
> And for games (a growing part of
> the RIA market), access to existing physics and game controller
> libraries is wonderful.
Yes, games is where JavaFX could have the biggest advantage, but its
desktop penetration is currently too low for most cases. Unless Sun
wants to "buy consumer apps" like Microsoft to gain marketshare, I
guess you'd need to wait for 50-60% JavaFX penetration to make serious
inroads there.
> Second, JavaFX is multi-screen. JavaFX runs on both desktop and mobile
> devices, and eventually TVs as well. And I don't mean that you can use
> one language to write two apps, like you can today with Java. I mean
> literally the same code can run in both places unmodified, with your
> application adapting itself to the UI constraints of that device.
> JavaFX gives you one download with one language, SDK, and set of APIs,
> for all of the screens. That's something that doesn't exist anywhere
> else. I'm a complete JavaME novice but I've been able to easily write
> mobile apps with JavaFX.
Firstly, I would argue that for any non-trivial application you need
to redesign your user interface for a mobile devices because of the
hardware constraints of these devices and because the user often wants
to do something different with the mobile device. Now from what I
know about JavaME, the amount of time you spent to writing the core UI
has been typically exceeded by the time it takes to test on all the
different phones you want to support and to get around the various
bugs in the JavaME implementation / vendor libraries.
So how again is JavaFX Mobile going to make that easier for
developers? Ok, it cuts down on the core UI developerment time, but
that's not where the bulk of the time was spent anyway. And if I
understood you correctly in RIA Weekly, then JavaFX Mobile for
existing phones runs on top of JavaME, won't have the hot-spot VM or
hardware (video?) acceleration - these two are reserved for new
phones, shipping with JavaFX built-in. So you'll get "old and new
JavaFX Mobile" with new JavaFX faster by an order of magnitude (latest
hardware, hot-spot, acceleration). So you either code your app to the
lowest common denominator ("old JavaFX"), looking really bad next to
that iPhone, or you just target "new JavaFX", erasing the "2 billion
Java phones" advantage.
Secondly, the Achilles heel of JavaME has always been distribution -
most developer want other people to use their software, which means
you start talking to a mobile carrier of your choice, get verified /
certified, and then try to get into their distribution channel. If
you want to get paid (and carriers aren't terribly interested in
distributing free apps), set up a billing relationship with the
carrier. Now rinse and repeat if you want to target more than one
carrier or more than one country. It took Apple to show the world how
to build an app store and make an attractive platform for
developers.
JavaFX TV is only for consumers, but I think there it's even worse for
developers. There have been Java standards for cable companies in the
US (http://en.wikipedia.org/wiki/OpenCable_Application_Platform) and a
global one for TV (http://en.wikipedia.org/wiki/
Multimedia_Home_Platform#DVB-J) for years, but they were used by the
hardware manufacturers or cable companies to write apps themselves,
not by outside developers. If you target set-top boxes, you would,
like in JavaME, need to test against the different set-top boxes and
then talk to the cable companies to distribute your app and get paid
for it. Good luck with that (although I think Comcast talked about an
app store a while ago)!
And how do you get your JavaFX app to run on a Samsung BluRay player -
shipping discs? The latest BluRay spec allows discs to load content
from the Internet, but I don't think it's meant to distribute
applications. And unlike a phone or a cable company, nobody has a
guaranteed billing relationship with a BluRay customer, so you have
set this up yourself.
> Components: JavaFX currently has only the TextBox component. You can
> use any Swing component in your application, however, even ones we
> haven't provided wrappers for. This lets you mix and match between
> existing Swing code and new JavaFX code. In addition, we are planning
> a full set of new components which will work on both desktop and
> mobile (Swing is desktop only), and will be CSS skinnable, support
> shaped and translucent boundaries, transitions, and all of the other
> things you expect from 21st century GUI components.
Sounds good, although it seems that you're just catching up to Flex
and Silverlight here. Will you have a charting library?
> I hope this addresses your concerns and I hope you will continue to
> watch JavaFX as it improves over the coming months.
I will certainly watch, though obviously I'm more excited about Flex
4. I also hope that in these discussions it becomes clearer for the
JavaFX team what the barriers of entry are for JavaFX in the Flex
market - to be brutally honest, your JavaFX pitch in the podcast
didn't sound like you really knew. And although I will probably not
use JavaFX for a while, a successful JavaFX would probably make Flex
better, so I wish you guys all the best.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
