The announcement of a new Desktop Application Framework JSR a few days ago has gathered a lot of interest. It also generated a good number of questions, which hopefully I'll be able to address in this post.
First and foremost, JSR296 is not the first attempt at creating a JSR on this subject. As Sven Reimers (@SvenNB) correctly pointed out to me, JSR193 was proposed by Adam Bien (@adambien) back in 2002. This JSR resembled JavaEE (then called J2EE) due to its container approach.
And now for the questions:
1. Should NDAF target only the desktop or could it go further into tablets and other mobile devices?
Considering the rise of tablets and mobile devices as we've seen so far it would be silly not to consider those enviroments as potential deployment targets. JavaSE8 and embedded Java have closed the gap in terms of compatibility and API convergence. This gap is very likely to shorten in future versions of the JDK. So yes, NDAF should break out of the desktop and reach out.
2. OK, so we jump into the JavaFX bandwagon and ride it like there's no tomorrow, right?
Not quite. JavaFX is poised to replace Swing as the defacto UI toolkit provided by the JDK. It's my personal opinion that JavaFX has not reached this spot just yet; Not with missing accessibility and other features found in Swing (actions everyone?). The JavaFX team has openly expressed that some of these missing features should be implemented by the community, and to that effort a set of open source projects have been created (ControlsFX, JideFX, MigLayoutFX, etc). However JavaFX will become the dominant UI toolkit in the embedded space, meanwhile we'll still have access to all other popular choices such as Swing, SWT, Qt, Lanterna (to name a few). Bottom line, NDAF APIs should be close to a particular UI toolkit where it makes sense (if at all). This is one thing that both Griffon and Eclipse4 do very well, as they can target multiple UI toolkits without compromising on performance and features.
3. How deep should the behavior be specified?
Allow me to reiterate what I believe what useful features a DAF should provide
- dependency injection via JSR330.
- common application structure.
- application life-cycle.
- localized resources.
- resource injection.
- localized configuration.
- decouple state from UI (binding).
- persistence session state (preferences).
- action management.
- component life-cycle.
- light-weight event bus.
- honor threading concerns (specific to UI toolkit).
- application extensibility via plugins (implies modularity).
- testing support (unit and functional).
- deployment profiles.
In my mind that would be the minimum set of features I'll define in NDAF. Of course others may differ; and this is precisely the point to bringing the discussion into the JSR space.
4. OK, so what about a full stack framework?
I think standardazing on a full stack framework would be far too much. That would be akin to saying all JavaEE applications must use JPA one way or another, without a chance of an alternative persistence option, or no persistence at all! If you look around at the different applications you're currently running you'll notice that all of them share some common behavior but not all have persistence capabilities; some don't even have preferences! Championing a fullstack as part of the NDAF JSR would be a turn off IMHO; however what can be done is prepare the NDAF APIs so that persistence (or any other non core behavior) can be added effortlessly, that is, we need API hooks and plugin capabilities. And no, I'm not saying we should go with with the OSGi route, but any of the implementors might choose OSGi to fulfil this requirement.
5. This is great! Can you pick my framework to make it happen?
I don't think it's that easy. First the framework you proposed must comply to the minimum set of features that NDAF should provide. Secondly, what about IP and licensing? There are some rules to be followed so we can't pick just any codebase out there. On the other hand, once NDAF goes public any implementors are free to choose how they retrofit their frameworks to conform to the NDAF spec, so eventually your framework can be made NDAF compliant.
6. I get it now, you just want to rub Griffon in our faces! BOOO!
I've openly confessed Griffon to be my passion. It's true that I consider it mature enough to fulfil the set of features I've put forward, after all it almost covers them all today. But it's not the only one that partially covers them. Here's a somewhat incomplete list of (mostly JavaFX) frameworks that also cover some of the features found in the list
- JACPFX
- JVx
- DataFX
- Afterburner.fx
- MvvmFX
- ObjectWheel
- Eclipse 4 Platform (JavaFX support provided by e(fx)clipse)
- JMatter
- Guts-gui
- NetBeans
Any of these frameworks/platforms can become an NDAF implementation, even the RI for that matter; again I believe Griffon is closer but the open discussion will clear that subject.
I hope this clears out some of the question brought by the first announcement. No doubt other questions will rise, so please keep commenting and share. Let's make NDAF a reality, together.
PS: a name for this JSR should be decided pretty soon or NDAF will stick 
