• Home
  • Events
  • About
  • New Desktop Application Framework JSR: Q & A

    October 12th, 2014

    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

    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 ;-)

    It’s time for a Desktop Application Framework JSR

    October 5th, 2014

    A few days ago an innocent tweet appeared

    cat is out of the bag: who’s up for a desktop application framework JSR? #javaone

    — Andres Almiray (@aalmiray) October 3, 2014

    That’s right, I’m thinking it’s time to discuss and formalize what a Desktop Application Framework JSR should be. It’s said that one who forgets the past is condemned to repeat it, yup, I’m referring to JSR296, dead and buried since 2009. According to Wikipedia JSR296 had the following goals

    • management of application life-cycle, startup and shutdown.
    • support for loading localized resources.
    • persistent session state.
    • support for loosely coupling actions to their presentation.

    Not bad but also not ambitious enough. It targeted a single UI toolkit (Swing). It’s main goal was to define runtime concerns, leaving out other important app development aspects such as testing and deployment. And it was proposed before other helpful JSRs (such as JSR330 and the upcoming Java Config JSR) came up. So why now? Why not revive JSR296 instead of proposing a new one?

    I believe the following features to be of great advantage when developing an application that targets the desktop:

    • 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.

    Some of these features are quite straight forward to understand, others might lead to a rabbit hole that may be too deep (should OSGi support be included for example?). This is why discussing in the open is a Good Thing(tm). Many of these features can be found in Griffon (my natural choice for an RI of this JSR at this point) but it you look at the Eclipse 4 Platform you’ll find out that it too provides many of them too. Coincidence? I. Think. Not.

    There’s a new UI toolkit found in the JDK since Java8: JavaFX. Both Swing and JavaFX can coexist, even within the same application. But these two are not the only toolkits you can choose from, there’s also SWT, Qt, Pivot, GTK and Lanterna (to name a few). The New Desktop Application Framework (NDAF (should come up with a better name)) should be flexible enough to accomodate any of these toolkits, not just a single one (Swing) like SAF did.

    JSR330 did not exist when JSR296 was proposed. It’s now pretty much everywhere. Java developers have found it to be a very useful item in ther development toolbox. JSR205 includes additional annotations that can further simplify component life-cycle management (@PostConstruct and @PreDestroy).

    The JavaConfig JSR can help with configuration and preferences. I urge everybody to have a look at what Anatole is proposing for this JSR and state your support if it makes sense to you too.

    Finally, with the push of Java8 running on smaller devices thru embedded Java, such as Raspberrie Pi, it also makes sense to target these devices with NDAF; after all Griffon 2.0 runs on Raspberrie Pi already ;-)

    What’s next? For now I’m collecting feedback from interested parties. So far input has been very positive with a few words of caution. Please comment and share the pros and cons of such initiative.

    From Java to JavaScript/TypeScript

    January 14th, 2014

    Experiences when porting the OpenDolphin client to the web

    dolphinIn spring of 2013 we started with a prototype of a JavaScript port for the OpenDolphin client, which at that time was only available for the Java platform and mainly used with Swing and JavaFX.
    We did a few demos with that prototype and found it to be valuable and promising such that we decided to bring it to production quality.

    This blog post describes the experiences that we made along the way.

    Non-functional requirements and technology choices

    For the sake of getting to speed quickly, the prototype had used a zoo of technologies:
    grunt, bower, require, jquery, angular, node, and a few more. For a production version, though, we
    wanted to have the fewest amount of dependencies such that a user of OpenDolphin.js
    would not run into compatibility issues with his own choice of libraries and their
    respective versions.
    We found namespacing and module management to be critical and decided to stay with
    require.js (with the option to drop that later) but drop all other runtime dependencies.

    Since OpenDolphin.js is a library (as opposed to an application) we expect that we
    have to maintain it over quite some time – a longer period of time than most
    current development tools will be available.
    That is: we can only use tools that produce tool-independent artifacts.
    This consideration ruled out tools like Dart and GWT for development since their
    generated JavaScript is not well-suited for development once the tool is

    We tried TypeScript for a week before we decided that it looked pretty much like what we
    needed (our state of information at the time of decision):
    – namespacing
    – modularization
    – abstraction over types (classes and interfaces)
    – type safety
    – code navigation (“where used”)
    – simple test facility
    – source-code debugging
    – very readable JavaScript source code generation
    In fact, we found the generated JavaScript to be more consistent and readable
    than what I had written manually – mainly because it wouldn’t have any of the
    dirty tricks that one can do in JavaScript.

    Experiences with TypeScript

    In hindsight, we should have experimented more before starting the real
    development and should have tested the distribution story. As it turned out
    I misunderstood TypeScript modules as being mainly a tool to provide
    namespaces – like packages in Java – but it is just as well a distribution
    mechanism. You see that when you try to “package” a module that spans
    over multiple files, which is not supported.
    A helpful voice pointed that out to me on stackoverflow and correctly
    mentioned that the documentation also says so (even though not very

    I was finally able to combine all my generated JavaScript in a single file
    with some Gradle/Groovy trickery but overall it costed me a day of
    investigation, trial, error, and fixing.

    We wasted two more days with hunting down two TypeScript errors that we
    simply didn’t expect to be possible: we ran into a situation where
    TypeScript inheritance silently didn’t work and on a second occasion
    we got two different instances of the same static reference.

    Lesson learned: avoid inheritance and statics even more than usual.

    This lesson actually turned out to be benefitial because it led to a simpler
    design, e.g. around the HttpClientConnector that we refactored from a
    subclass into a Transmitter interface that the ClientConnector points to
    with NoTransmitter and HttpTransmitter as implementations.
    We plan to refactor the Java version accordingly.

    While it first felt a bit weird that TypeScript cannot compile all
    our *.ts files at once, we learned to value the fast incremental compile
    especially when combined with the Intellij IDEA file watcher setup.

    In the beginning TypeScript feels as if it made your JavaScript more object-
    or better say type-oriented. But the real benefit is that it
    very much improves the “functional programming” story, which is already
    pretty strong in JavaScript but TypeScript adds more structure to it
    when declaring, implementing, or calling functions.
    This is kind of an under-marketed feature of TypeScript.

    We struggled a bit with how to organize *.ts files and references
    between them in a way that works consistently in all scenarios
    – when delivered from a web server or node.js
    – when loaded from a static html file
    – when testing
    – when debugging
    and I’m afraid our solution is not optimal since it led to
    quite a lot of duplication in the references (relative file paths).
    It would be helpful if the TypeScript documentation gave better
    advice on the topic or propose best practices.

    The TypeScript documentation was generally a doubly-edged experience.
    While the language part is well documented, the API is not.
    When searching for a feature I often landed at places where the
    shape of that feature was discussed between the developers
    but could not find any kind of “user guide”.
    But, well, it is version 0.9 and it is free, so we should not complain
    especially since the response time for questions on stackoverflow
    was awesome.

    IDE support inside Intellij IDEA is pretty strong and has helped us a lot.
    Basic things like highlighting, navigation, code completion, and so on
    work reasonably well and certainly better than for plain JavaScript.
    One should not expect the same sophistication like for Java or Groovy,
    though, when it comes to refactoring across multiple files.

    Would I decide for TypeScript again? Definitely yes!
    But I would allow more time for finding the best setup.

    OpenDolphin for the web

    OpenDolphin is use-case driven. We only include a feature, if we have
    a use-case for it and with any use case comes a demo. This nicely
    leads to the comfortable situation that every feature is used
    in at least one demo.

    The additional feature of OpenDolphin.js over the Java version is:
    “it also works in the browser” be it desktop or mobile.
    Consequently, we created some demos.

    Creating the demos immediately revealed how well the OpenDolphin architecture
    (structure, concepts, abstractions) fits for web development. Having
    – views in HTML5 that are totally separate,
    – a binding technology of your choice
    (JavaScript, TypeScript, GSP, vanilla.js, angular.js, GWT, …), and
    – server-side control over the presentation models with Java
    leads to a new level of enterprise applications.

    These new enterprise applications are automatically consistent,
    they update their content immediately, they share information with other
    users, and facilitate user collaboration at a totally new level.
    One can see these features boiled down to the bare minimum in the chat demo.

    Best of all: desktop, web, mobile, and even embedded applications all share
    the same information at runtime and the same programming model!
    They all connect to the exact same server-side application logic.

    The web for application development

    For anyone with experience in desktop UI toolkits like JavaFX, Swing, or
    equivalents web development feels casual and coincidental.
    Obviously, one can “get things done” but it is hard to say whether they
    only work by chance, what the actual constraints are, and on which
    guarantees one can build (pun intended).

    Take a slider as in the master-detail demo.
    There is no such control in HTML5 – as there are no
    real “controls” in the browser anyway. Ok, you can use the “input” element
    with type “range” in some browsers. But which events are fired when
    you drag the thumb? And are they fired while you drag or only after
    stop? Happy testing in all your supported browsers!
    Now try to enlarge the thumb for touch support with CSS – and
    consider that some browsers use circles and others use squares…

    I wouldn’t even go into more advanced controls like tables. HTML5 has no control
    that even remotely compares to what you have in the most basic JavaFX table view.

    But sliders and tables are only the tip of the iceberg. There are no controls.
    There are no layout managers. There is no usable logging. Basic datatypes are missing.
    Performance characteristics of existing datatypes are unclear. Object lifecycle
    is unclear. Scoping is counter-intuitive.
    To make matters worse, you can add ever-changing libraries that try to fill these gaps.
    Welcome to dependency hell!

    In short: the browser is a problematic execution environment.

    Now, if developing applications for the web is so immature, why do we even
    bother creating OpenDolphin.js? Because the web is everywhere and easy to access
    and there is an undeniable request for enterprise applications to have selected parts
    of their functionality visible and accessible on the web.

    The web makes an extremely good distribution channel for information.
    While creating the OpenDolphin web demos, I started to make extensive use of
    the browser features for developers (I know, I’m late to the party).
    These are extremely helpful while developing and occasionally scary when they
    reveal what many of the websites I visit are doing on my machine.
    One should always keep in mind that there is no privacy in the browser.

    As it stands today, we can recommend this mix for enterprise applications:
    desktop (preferrably in JavaFX) for the office worker to safely edit the core of the system
    web and mobile “extensions” for special purposes
    (dashboard, directions, check lists, mobile data capture, location, local sensors, field work)
    all conveniently integrated in the OpenDolphin architecture.

    Lessons learned

    When creating the JavaScript implementation of the OpenDolphin architecture, we of
    course profited much from having the Java implementation as a blueprint.
    But it actually turned out to be benefitial both ways: the Java version also
    profited since it was implicitly reviewed along the way and we could improve it in two places
    where even our 100% test coverage was not good enough to uncover a bug.

    Furthermore, the architecture was scrutinized a second time and I feel
    “implement a second time in a different technology” is a great validation
    technique for any architecture. This also led to a better distinction between
    rules and concepts of the architecture versus special design decisions for
    each implementation.

    JavaScript/TypeScript has less features than Java – especially around
    concurrency and inheritance -, which forced us into simpler albeit less powerful designs
    that we may partially bring back to the Java (“compact-0 profile”) implementation in the future.

    It was a pleasure to see that with OpenDolphin.js we can reap the same
    architectural benefits for web applications that we experienced for desktop apps
    while adding the web as a new option for exchangeable visualization technologies.

    That was what we were hoping for but then to see it working out so well
    has been a huge reward for the effort.

    Dierk König

    P.S. OpenDolphin.js will be part of the imminent 0.9 release of OpenDolphin.

    Using Open Dolphin with pure Swing

    June 28th, 2013

    Today I would like to show you how a pure Swing based application can benefit from using Open Dolphin even if you are not planning to migrate it to JavaFX.

    Although open-dolphin comes with many JavaFX examples it is not bound to JavaFX at all. In fact it does not require any specific UI toolkit.

    You can get the source code for this example ready to build from github:

    1. git clone https://github.com/svene/opendolphin_swing_example.git
    2. ./gradlew build (or ‘gradlew.bat build’ if you are on Windows)
    3. ./gradlew :combined:run

    The included example consists of just four simple widgets: a text field, a label and two buttons.
    I did not spend any effort in making it visually attractive since I want you to concentrate on the open-dolphin aspects.
    This is how the GUI looks like:


    and here is a video demonstrating it’s behavior:


    The following picture depicts how the individual widgets of the GUI are connected to the single presentation model:


    Whenever a button is pressed a new value for the color is set on the presentation model (PM for short). And whenever the PM’s value changes both the label and the textfield are updated accordingly. In addition whenever the value in the textfield is changed by the user the value will be written back into the PM which in turn will update the label and so on.

    In other words: each widget only talks (is bound) to the PM and not to other widgets. This also means they are  only depending on the PM but not on other widgets. You can find more information about the PM concept on open-dolphin.org.

    Some things worth to mention about the code:

    When we invoke

    as decribed earlier the application starts up with ApplicationInMemoryStarter. If you have a look into it you find that it uses SwingUiThreadHandler so that Dolphin can make use of Swing’s thread handling using:

    The GUI (see ApplicationFrame) makes use of my preferred layoutcontainer: MigLayout.

    Widgets are bound using Open Dolphin’s Binder class. The label for example is bound to the PM with a convenient DSL as follows:

    which means: whenever the color of pm1 changes update the label’s text accordingly. The textfield is bound in the same way. Since text fields in Swing are a little uncooperative in regards to binding I used Jean-Marc Astesana’s CoolJTextField (see http://stackoverflow.com/questions/3953208/value-change-listener-to-jtextfield for the details).


    This blog post gave you a starting point on how to apply the presentation model concept with Open Dolphin to a Swing application. But we only scratched the surface. If you would like to learn more about these intersting topics visit the Open Dolphin website or get in contact with Canoo.

    Sven Ehrke (@syendar)

    AfterburnerDolphin – Effective enterprise JavaFX development

    May 17th, 2013


    During the last JavaOne, Canoo announced the open sourcing of Dolphin.
    OpenDolphin is a library that provides a remoting solution to bridge the world of Enterprise Java and Desktop Java or other client technologies (mobile, web).

    Since then, a lot has happened around OpenDolphin and it keeps gaining more and more attention.
    For me personally, it was from the first time I heard of it a very interesting project, but due to daily business and other projects I didn’t have the time to get into it.
    Using JavaFx as the first client technology to be implemented was also a little hurdle as I haven’t done any serious work with JavaFX, yet. But now, I’ve finally found some time to play with JavaFx and OpenDolphin ;-).
    (Besides, there is an JS implementation of OpenDolphin – it proves that OpenDolphin doesn’t tie you to a client UI technology.)


    As I attended to Adam Bien’s Airhacks Workshops in March, he introduced the Afterburner.fx mini-framework to the audience and released it a few days later.

    Afterburner.fx is a minimalistic MVP framework for JavaFX that provides
    “Zero-Configuration” dependency injection (DI) of models and services
    Convention-based unification of presenter, view, FXML and css.


    Thus it enables the usage of the JavaFX scene builder (a UI design tool) to implement a clear seperation of layout and logic (as the layout is encapsulted in the xml). In his talk “Enterprise JavaFX 8” Adam describes it as an implementation of “inversion of control”.
    The outcome is a very powerful set of lightweight technologies to build JavaFx applications.

    The wiring between the UI XML and the code a pretty minimal. On the one hand, in XML, you just need to define the controller class:

    And optionally, event handler methods can also be set via XML with

    In the code, the UI components get injected by the @FXML annotation and the name used as fx:id :

    Combine the power

    My idea on the moment I saw it was to bring those two projects together to benefit from the features of both projects:

    • A clean and easy way to create the UI and build up the client
    • a powerful and non the less easy to use library for client-server communication and clear speration between logic on the server-side and UI-related code on the client with open-dolphin.


    You can find the outcome of this idea at my AfterburnerDolphin project at github.

    It demonstrates the things mentioned above:

    client structure

    In the client module, you can find a clearly structured app, the design and layout clearly seperated (as extracted to xml and css files) from the logic (look at the App class and the DemoPresenter).

    It’s all tied together via DI and convention-based confguration of afterburner.fx .

    The client creates a PresentationModel and binds the button text value to the value of that model.
    (DemoPresenter, Line 43)

    On a button click, the client communicates via OpenDolphin with the server (server module, ApplicationAction) where the command for a new value (current date) of the presentation model’s attribute is created and send as a response.

    (ApplicationAction, Line 17)

    That demonstrates how easy this set of technologies lets you set up a well structured multi-tier application 😉 and implement a roundtrip between client and server.

    Any business logic can be handled on the server, the client only need to implement the presentation. And the implementation and maintenance of the client UI is eased up by the clear structure implemented with the help of afterburner.fx .

    The UI of this sample application is very simple, as you can see from the screen shot – before and after click on the button. The date used as die new button text is set on server side.



    I think, the combination of AfterBurner.fx and OpenDolphin provides a very powerful featureset.
    At first, it’s easy and quick to setup and design UI Layout with Scence Builder.
    After that, AfterBurner.fx and OpenDolphin allow you to build an application with clear, distinct seperation between layers:

    • UI layout (in XML)
    • UI logic (in client code)
    • Business Logic (and more) (in server code)

    You can be up and running very quickly with a short time to initiate application development. With the clear seperation, I would expected the setup to provide the foundation for a very maintainable project.
    And with OpenDolphin you protect your investment as you can very quickly provide an multi-channel application (providing an mobile app UI based on the already developed server code) or switch to another UI technology and reuse the business logic implemented on server side.

    Further steps

    Fork AfterburnerDolphin on github.

    Find out more about Afterburner.fx, visit the Afterburner.fx Homepage.

    Get more information on OpenDolphin with the OpenDolphin documentation.
    Or look at the OpenDolphin videos on youtube.