posts/2009/javafx-backwards-compatibility-and-the-path-forward/index

[JonathanGiles]

JavaFX, backwards compatibility, and the path forward

https://jonathangiles.net/posts/2009/javafx-backwards-compatibility-and-the-path-forward/

[JonathanGiles]

Auto-imported comment, original author: Steven Herod Comment posted on: June 9, 2009

I'm an early adopter of JavaFX, with TwitterFX being what I consider a significant JavaFX based application in terms of scale.

The recent changes from JavaFX 1.1 to 1.2 have given me alot of work to do with hundreds of compile errors, removed API's, changed behavior making me rework my app.

But I can see the improvements in the API in terms of greater consistency and more power.

So despite the pain, I prefer the breaking change as long as we're always moving toward a simpler outcome.

This language and runtime is too young for us to be tied to the oversights of the (very recent) past.

And I want a basic HTML rendering component. Now. :O)

[JonathanGiles]

Auto-imported comment, original author: Tim Vance Comment posted on: June 9, 2009

I definitely lean towards the second. There is nothing more frustrating that bumping into some API only to find out later how dangerous or bad it is; but it was kept for backwards compatibility.

In general I'm happy to hear that JavaFX seems to be growing up right, but do think that there is still a place for a "Swing 2"?

And more generally do think JavaFX could ever be used to build the GUI of an app that is Microsoft Office?

[JonathanGiles]

Auto-imported comment, original author: Jonathan Comment posted on: June 9, 2009

@Tim Vance: Good to hear from you again :-) I think JavaFX is some way off of making it easy to build an application such as MS Office, but I can certainly see it becoming more possible in the coming months/years.

Swing 1.5/2.0 is growing by way of the <a href="http://swing-generics.dev.java.net&quot; rel="nofollow">Swing Generics project</a>.

Thanks for your response. I agree that having cruft in your API is not good. I have word from high sources that Richard Bair, in charge of the JavaFX API, is the king of API, and it seems he is putting considerable consideration towards the API to prevent introducing cruft.

[JonathanGiles]

Auto-imported comment, original author: Jo Voordeckers Comment posted on: June 9, 2009

I'm definately in favor of continuously evolving and cleaning up the API. Once JFX has a more or less complete RIA offering and theres significant adoption we can revisit this. The iphone sdk had breaking changes as well...

[JonathanGiles]

Auto-imported comment, original author: Alex Comment posted on: June 9, 2009

I'm surprised that no one will talk about the elephant in the room. Namely, that JavaFX is not redistributable. Any apps you make must link dynamically to Sun's JNLP for deployment. It's in the license, and talking to some insider's at Sun a few months back, there is no immediate plan to change this. This renders JavaFX completely useless for us serious desktop developers who must distribute complete work with native installers. This betrays a jaw-dropping lack of direction from Sun.

[JonathanGiles]

Auto-imported comment, original author: Jonathan Comment posted on: June 9, 2009

Alex,

I'm sorry but I really don't understand what you're saying. The elephant in the room is not visible to me as I've not heard of this JNLP issue you mention. Can you please clarify what you are saying?

-- Jonathan

[JonathanGiles]

Auto-imported comment, original author: Stephen Chin Comment posted on: June 9, 2009

This is my third iteration at updating and fixing several large codebases based on changes in the JavaFX APIs, and while there was a lot of change to deal with (see http://steveonjava.com/2009/05/31/javafx-1-2-top-10/), most of it was isolated to the new or less stable portions of the codebase (notably Controls, Layouts, and Stylesheets).

What I think would help greatly to make sure that the released API is going to serve the community well would be to have a public beta prior to launch. This would give the entire community a chance to give feedback on new and evolving APIs before they get set in stone.

[JonathanGiles]

Auto-imported comment, original author: Jonathan Comment posted on: June 9, 2009

@Stephen Chin: I agree with the public beta - this is what I was asking for in option two. It would be nice to see this approach considered and discussed further. Then we all have a certain timeframe to thrash the API and make sure it meets the expectations and needs of the public. Once the beta is complete, we can't complain about the API any further :-)

Thanks for the feedback!

[JonathanGiles]

Auto-imported comment, original author: Steven Herod Comment posted on: June 9, 2009

Each JavaFX based app's JNLP file refers to the URL of the underlying JavaFX runtime as a dependancy.

This runtime is hosted on Sun's servers.

On one hand it means that there is leveraging in relation to getting the runtime on computer's (i.e. another person's app helps bootstrap your with caching the runtime). But if the user is offline or behind a firewall, this may be an issue.

[JonathanGiles]

Auto-imported comment, original author: Alex Comment posted on: June 9, 2009

Refer to the JavaFX license:

5. Restrictions.

(a) The copies of Software provided to you under this Agreement are licensed, not sold, to you by Sun. Sun reserves all rights not expressly granted. (b) You may make a single archival copy of Software, but otherwise may not copy, modify, or DISTRIBUTE Software.

[JonathanGiles]

Auto-imported comment, original author: Danno Ferrin Comment posted on: June 9, 2009

I want to integrate FX into my projects. But as long as they keep breaking stuff and making the binary interop a moving target, I cannot spend my ever shrinking free time integrating it. So whether they get other issues right or not doesn't matter, I won't really be interested in it enough to use it until there is some public commitment that binary interop will become more stable.

[JonathanGiles]

Auto-imported comment, original author: Alex Comment posted on: June 9, 2009

Many of us have no interest in writing WebStart apps. I work on one fulltime and it's still a deployment nightmare. Or Applets. Users hate them and they still crash the browser despite Sun's claims on 1.610. I speak from personal experience. So, those of us who want to write desktop apps or Java Swing RIAs cannot use JavaFX in any way.

[JonathanGiles]

Auto-imported comment, original author: Danno Ferrin Comment posted on: June 9, 2009

Oh, and also, what Alex said. Until distribution is fixed as well I cannot even begin to consider using it professionally. The environments I deploy to are usually totally disconnected from the internet at large, often disconnected from any network at all at runtime. FX needs some easing of the license WRT redistribution.

[JonathanGiles]

Auto-imported comment, original author: Per-Erik Svensson Comment posted on: June 9, 2009

I still believe that the biggest issue with jfx is with it's friendliness with swing. It does not exist. I cannot understand why it is not possible to create jfx-widgets that are useable in swing. It might be that I'm to ignorant on the subject but then someone, please explain it to me. :)

Imagine how much wider the adoption would be if both swingers and fx:ers could create widgets in jfx and share their work. JavaFX would quickly get a huge number of "part time adopters" in the swing community. These people would create jfx code used in their existing swing projects and share this code with the full time (early) adopters.

Also, why learn javafx as a swing developer? Why not learn Flex/Air or Silverlight? One argument is because it runs on the java platform. A much (much) better argument is that it can be used in existing java/swing software. Only problem is that the better argument is not true. I was hoping Amy Fowler would show us this in the extream gui makeover, but sadly she didn't. At least not in a way that would be easy in large scale desktop applications.

So, both Adobe and Microsofts solutions are still open to me when starting new projects. They wouldn't be if I already knew JavaFX. I would know JavaFX if I could use it in my existing projects. This is what I want in the future for JavaFX!

[JonathanGiles]

Auto-imported comment, original author: Alex Ruiz Comment posted on: June 9, 2009

I don't have too much to add to what have already been said. I agree that JavaFX needs to be "more stable" to have greater adoption. In my case, I haven't spent as much effort as I wanted in FEST-JavaFX (library for functional testing of JavaFX UIs) because I was in a "wait and see" mode, waiting for JavaFX to stabilize. I sincerely hope that starting with JavaFX 1.2 this will be case, so I can continue my work on FEST.

-Alex

[JonathanGiles]

Auto-imported comment, original author: lqd Comment posted on: June 9, 2009

Whenever there's a change, breaking something or not, the faster the feedback loop the better. That's especially important in a rapid changing and not yet mature environment. That's why i'd recommend two obvious possibilities that we have discussed before: 1) nightly builds of the runtime 2) open sourcing (which would also solve the redistribution problem).

I should probably note that usually in most licensing terms, if you're doing in-house apps, you can deploy it to your colleagues however you want, as this is not considered distribution per se, then again IANAL. I thought this was worth mentioning since most of the web apps in the world are behind firewalls in intranets, this web start deployment requirement should have no effect on your end if you're in this situation, and you could do it in javafx.

On a less technical aspect, once again more communication could be helpful, since javafx developers right now are kept in the dark as of what's going to happen over the next releases as there is no roadmap, and JIRA is mostly secret.

I've said before i think an easier path of migration would be a fully transparent and perfect integration with java/swing. I still think it's true, but i'm not sure it would be for the right people. Java/swing developers don't seem to be the primary target demographic: sun describes them as "web scripters" (aka flex/silverlight developers ?), which might seem odd at first. But, out of all the java/swing developers in the world, i'm not sure there's a big enough percentage interested in effects, animations or better ux, or needing them. This is exactly the opposite for flash where it's the "only" thing it does, and they needed the opposite enterprisey stuff, like buttons and all. So while i think it would lower the barrier to entry i don't know if many more people would jump onbard for certain. The java/swing developers interested enough can certainly try and learn javafx on the side, put it to use in new projects and not existing swing apps.

-Rémy

[JonathanGiles]

Auto-imported comment, original author: Tom Comment posted on: June 9, 2009

Stable API's within a major release (1.x), so during patches and minor updates.

Break API once every two years when release a new major release (x.0) Unfortunately that point has not been reached yet with JFX.

[JonathanGiles]

Auto-imported comment, original author: Chas Emerick Comment posted on: June 10, 2009

Three big problems:

• redistribution issues, as described above

• continued fixation on JavaFX script (which is not going to win any hearts or minds (or, perhaps not my heart or mind) vs. any of the other fantastic JVM languages being developed in the commons, e.g. clojure, jruby, etc)

• no swing interop

All three of these issues are essentially showstoppers. Almost worse than that is: what's javafx's raison d'être given swing + any decent non-Java JVM language. For what we do, I've not seen anything compelling, and I think it's clear that there are many others with the same perspective.

[JonathanGiles]

Auto-imported comment, original author: Mike Azzi Comment posted on: June 10, 2009

I definitely vote for option two. JavaFX Script and the platform are still evolving, and many pieces are still not there yet. Plus the installed is almost non existent. It would therefore be very unwise a this point in time to shackle the platform down with backward incompatibility restrictions. For instance, I would really like to see added to the language, and/or the API some nifty declarative syntax to support the actor based concurrency model, instead of the thread based model that we have right now. I would like for the language to offer a solution to the concurrency problem as elegant as its solution to the binding problem. And I believe the most optimal way to do this is if you are not tied down backward incompatibility constraints.

[JonathanGiles]

Auto-imported comment, original author: Andres Almiray Comment posted on: June 10, 2009

I believe option #2 is fine, JavaFX is still in the early adopters phase (after +2 years no less) so getting the API right is a Good Thing. However as @shemnon mentioned makes the job harder. But what really makes JavaFX a fish out of water is its distribution story, until it is fixed JavaFX apps must be tethered to a network connection, many enterprise apps do not allow that easily.

[JonathanGiles]

Auto-imported comment, original author: Alex Ruiz Comment posted on: June 10, 2009

Like Stephen and lqd mentioned, a faster feedback loop is necessary:

1. Nightly builds
2. Public betas
3. Better versioning numbers: 1.2 was a major change (could be subjective,) probably labeling "2.0" would have been better

-Alex

[JonathanGiles]

Auto-imported comment, original author: PhiLho Comment posted on: June 10, 2009

I agree with Steven, even if I haven't done yet a real application, mostly small test scripts. Lot of stuff was broken with Java 1.2, but I don't mind rewriting (at this point), because the changes are in the right direction: the Control/Skin becoming Control/Skin/Behavior is a good thing, improving separation of concerns. At least at the debuts, I prefer breaking changes, they will be stuck when people will start writing big applications...

[JonathanGiles]

Auto-imported comment, original author: Richard Osbaldeston Comment posted on: June 10, 2009

How many of these problems are being caused by JavaFX abandoning the JCP with JavaFX and Jigsaw (at least the open aspects) and pretty much handling them as some secretive Skunkworks project?

Just ask @lqd about the sudden removal of a lot of the animation parts of the Scenario APIs in JFX 1.2. @lqd - If you remember I did warn you about that 'implementation detail' terminology. I do wonder when we're going to see these new contribution servers/services that'll be needed for contributors to work on OpenJDK designs/specs/code at the same level as Sun staff. Larry didnt seem to talk much about their commitments towards openness (but then I wasn't there).

On the other hand JFX is a work-in-progress pieces of the puzzle are still being fitted into each release, as such the APIs are taking shape as needed. They're working in a very compressed timescale with apparently very tight developer resources (compared to adobe/microsoft) so corners needed to be cut. APIs in one draft are rarely 'perfect' nor efficient so they're possibly keeping the implementation private to prevent any ongoing curn upsetting developers too much. The JNLP distribution at least introduces a kind of versioning dependency system that allows them to change APIs and limit the breakages to code needing porting between two versions. I take it javafx1.0, 1.1 examples still run OK? (will they always?)

I've always questioned who the developer market for JavaFX really is.. Given the increased production values inherent with dynamic effects and animations I think its better suited to interaction designers and new media producers not your typical Java/Swing code monkeys. I doubt they'll be cutting any code nor working at the API level.. it's way too low for most creative endeavours. If JavaFX stays kinda half &amp; half you need both the deep Java2D/EDT threading knowledge and great creative skills it'll never get much momentum (or @Kirillcool will get very rich). Currently we dont see these creative designers and Java/JavaFX crowds mix and I wonder if simply building JavaFX is enough to start changing that?

What I'm struggling with is the collapse of demand for desktop apps (and Swing developers http://tinyurl.com/nyn2po) and a even greater lack of demand/jobs for JavaFX. As a client-side Java developer I feel left in a very exposed position. Swing skills don't translate to the HTML5/Ajax/JS/HTML/CSS domain that replaced them. Nor is it clear Swing coding skillz translate all that well to JavaFX either if you think it'll be the web and new media production companies to be the ones to take it forward. Designers with skills in Flash/After Effects/Interaction Design etc.. Are Swing devs washed up? how do you survive the gap years? Suggestions on a postcard.

[JonathanGiles]

Auto-imported comment, original author: Richard Bair Comment posted on: June 10, 2009

Brian Goetz and I have talked about concurrency on several occasions, and actually we've been quite careful not to paint ourselves into a corner over concurrency. I don't know if we'll have it in the next release, or the one following, but we definitely have some plans cooking for concurrency. One thing we are definitely NOT going to do is expose the full threading model to the user -- there won't be semaphores, locks, concurrent queues, etc. If you need those, dip into Java (and there will be API for guiding down this path as well). From FX script, it'll be dead simple, and Task based. At least, that's the plan :-)

[JonathanGiles]

Auto-imported comment, original author: Josh Marinacci Comment posted on: June 10, 2009

Thanks for starting this thread, Jonathan. Yes, we greatly appreciate the discussion.

[JonathanGiles]

Auto-imported comment, original author: Mike Azzi Comment posted on: June 11, 2009

Thanks Richard for the reply. About concurrency, here's what I think: JavaFX with its elegant, language level binding support, brought the dataflow programming model to the mainstream and to the average developer. The binding support allowed us developers to model state changes in running applications as a (directed?) graph of data flowing between operations. Which, according to wikipedia is what dataflow programming model is all about. As such, I believe the actor based concurrency model is the perfect fit for this type of programming as it allows us to seamlessly blend the dataflow model, with the concurrency model. Imagine for instance being able to bind on the results of a set of actors before pushing the data downstream (Software Transactional Memory anyone?). How powerful can that be?