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


    JavaOne 2011 Thursday and wrap-up

    October 7th, 2011
    Opinions expressed in the post are solely my own and not necessarily those of my employer.

    Thursday started with the Community Keynote. Well, it actually started with a 25 minutes IBM presentation about their cloud story. This had obviously nothing to do with the topic of the event and later speakers pointed this out rather frankly. At least it was interesting to hear that there is a job title like “Cloud Architect”.
    The real part of the Community Keynote started with a quiet moment to honor Steve Jobs.
    Later on, various winners of the Duke choice award and JUG luminaries cared for a lighter mood again, presented their work and asked the audience for participation in their local JUGs and in the advancement of Java via the OpendJDK. The JavaPosse appeared on stage and presented a funny show.
    It was also announced that many of the JavaOne talks will be available on parleys.com, which provide by far the best experience when it comes to viewing live-captured talks.
    Afterwards I attended the ZeroTurnaround (JRebel) talk on classloader issues. The rather big room (~300 ppl) was packed and left the impression that many Java developers share a common pain around classloaders. It was a good talk, covering the basics and typical pifalls. The only surprise for me was *how* easily you can end up with a classloader leak.
    In order to improve my fathering skills, I went into Ken Sipe’s talk on “Rocking the Gradle”, where I met Adam Bien. Ken is a great presenter. However, convincing the crowd is a challenge especially as many Maven users seem to suffer from the Stockholm syndrome.
    Then onto “Visualization of Geomaps and Topic Maps with JavaFX 2.0”, which had some interesting visuals captured here.
    For me JavaOne 2011 finished with Jim Clarke and Dean Iverson on GroovyFX, where they made some really good points suggesting that Groovy is the best language to drive the JavaFX 2.0 API.
    As a side note, James Weaver introduced me to Jim Clarke by pointing out “He is from *Canoo*”. Then the discussion went into how well-known Canoo is in the community and that all employees must be true geniuses to achieve so much with so few people 🙂
    Fazit: Still, JavaOne is nowhere near where it was before the Oracle acquisition both in terms of size and in terms of being an unparalleled community experience. Distribution all over various hotels just doesn’t feel right. However, meeting friends has been and still remains the most important part of JavaOne and the conference still delivers on that account.
    Important topics were new Java versions, JavaEE (+cloud), and Java for the Desktop with 50+ talks on JavaFX. Whenever the audience was asked about which alternative languages they use, Groovy was the clear winner. It appears that in the mainstream, Groovy has become the default choice for dynamic programming on the JVM.
    The topic of concurrent programming was in my eyes underrepresented. Guillaume and myself had simple usage of GPars in our demos but for such a big and increasingly important topic the coverage should be much more extensive.
    Finally, some visual impressions.
    Good-bye SF
    Dierk Koenig


    JavaOne 2011 Wednesday

    October 6th, 2011

    Opinions expressed in this post are totally my own and not necessarily that of my employer.

    Wednesday started with the infamous “scriptbowl”, a competition between various scripting languages. This year the contenters were JRuby, Groovy, Scala, and Clojure. I wondered whether Scala considers itself a scripting language but obviously they either do or just seek the opportunity to be on stage.

    To keep a long story short: Groovy has won this event for the third time in a row! This year the race was tied with Scala. Guillaume presented Groovy in the typical Groovy-idomatic style and explained every single line of his concurrent visual analyzer for Google+ postings. Dick Wall presented only non-idomatic Scala code. I interpret this as: to make Scala appealing you have to make it look like Groovy. Furthermore, he presented Kojo, which is a great interactive learning environment written in Play/Scala. In contrast to all other presentations, this was not specifically created for the scriptbowl, nor was it written by the presenter, nor was it clear how much effort went into it, nor did the audience see a single line the implementation code. How much this skewed the comparison, I leave to everybody’s judgement. The show was good, though.

    I felt a bit sorry for Clojure. It is a great language and deserves a presentation that is more visually appealing to convince the crowd.

    Afterwards, I attended a hands-on lab for “rapid enterprise development with netbeans”, which was essentially creating a Swing app for database CRUD actions. If I remember correctly, I did the exact same task 1997 with JBuilder. It left me with the feeling of “Yes, it works” but it is not less complex than it was 13 years ago.

    Early afternoon Gerrit Grunwald (better known as @hansolo_) presented his work on simplified custom components for Swing. Given that he speaks about an activity that is both utterly important and highly underadvertised he would really deserve speaking at the center stage.

    Graeme Rocher’s great session about Grails, polyglot datastores (hibernate, jpa, redis, mongodb, …), and the cloud was overshadowed by the news that Steve Jobs has died. Accidentally, the demo application was about showing a BBC News stream, which displayed this information live on stage. Both the presenter and the audience were equally touched.

    The day officially ended with a big event at treasure island. I decided to not go there, though, and meet the former Canooey Denis Antonioli in Berkely where we had a great evening.

    Dierk Koenig


    J1 Session Blog: Swing Rocks – A Tribute to Filthy Rich Clients

    June 4th, 2009
    The two speakers (Pär Sikö, Martin Gunnarsson) showed off an RSS reader (Feedjii) built with Swing which looked a lot like the pimped up applications of Romain Guy. They started off  by presenting some real world examples of horribly looking Swing applications. Then they revealed their recipe for cool looking Swing applications: subtle effects, smooth animations, and custom components. For each ingredient they showed how surprisingly easy it is to implement it. They also covered the area of performance and gave a few hints on making a user interface really smooth. For this, developers have to look into: hardware acceleration flags, timing issues, caching images, image compatibility, and avoiding unnecessary transparency. They didn’t have a lot of material to talk about, though, and after 45 min they already started taking questions. Therefore, on the one hand I got confirmation again that one can build very nice user interfaces with Swing and it is not too hard provided a good UI designer is at hand. On the other hand I was slightly disappointed because I was expecting a lot more. BTW, there is a blog about developing Feedjii and it can be found here: http://www.swing-rocks.com/

    css.php