• Home
  • Events
  • About
  • Java Performance Workshop | December 2-5, 2014 | Basel

    October 22nd, 2014

    Java Champion Kirk Pepperdine will give a Java Performance Workshop on December 2-5, 2014 in Basel. He will provide you with techniques that have been proven to improve your ability to find and fix performance bottlenecks. During the four-day workshop you will learn:

    Java Performance_Button
    • Quickly identify the root causes of poor performance in your applications
    • Eliminate conditions that will prevent you from finding performance bottlenecks
    • Find critical supportive evidence before deciding on a potentially expensive course of action
    • Find performance issues before they make their escape into your production system
     
    Please find the content of the training days as well as price information on our website. JUG members will get a 10% discount.

    Registration:
    Please use the registration form on our website or send us an email to services@canoo.com.

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • email
    • Print
    • Twitter
    • LinkedIn
    • XING
    • Facebook
    • Google Bookmarks

    Enterprise JavaFX | October 20, 2014 | Basel

    October 20th, 2014

    Enterprise JavaFX

    Which issues have to be considered when it comes to the development of business applications with JavaFX? This question is answered by Hendrik Ebbers during the Canoo Tech Talk “Enterprise JavaFX”.


    Date:
    Monday, October 20, 2014 (free entry)

    Program:
    17:15 arrival
    17:30 Canoo Tech Talk “Enterprise JavaFX”
    18:30 snacks & networking

    Location: Canoo Engineering AG, Kirschgartenstrasse 5, 4051 Basel

    Registration: is not required

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • email
    • Print
    • Twitter
    • LinkedIn
    • XING
    • Facebook
    • Google Bookmarks

    JavaOne After Event | October 15, 2014 | Basel

    October 15th, 2014

    JavaOne

     After Event

    Java_duke

    Experience the talks of our JavaOne speakers Michael Heinrichs, Andres Almiray and Ixchel Ruiz.


    Date:
    Wednesday, October, 15, 2014 (free entry)

    Program:
    17:00 Arrival
    17:15 Talk “Do-It-Yourself Usability Design for Developers”
    18:15 Break
    18:30 Talk “Gradle: Harder, Better, Stronger, Faster”
    19:30 Apéro and fun

    Location: Basler Versicherung, Aeschengraben 21, CH-4002 Basel

    Registration: Please use either our registration form or send an email to: services@canoo.com.

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • email
    • Print
    • Twitter
    • LinkedIn
    • XING
    • Facebook
    • Google Bookmarks

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

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • email
    • Print
    • Twitter
    • LinkedIn
    • XING
    • Facebook
    • Google Bookmarks

    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.

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • email
    • Print
    • Twitter
    • LinkedIn
    • XING
    • Facebook
    • Google Bookmarks

    css.php