Steve On Java - JavaFX

James Gosling, the original Java NightHacker (see his great blog at http://nighthacks.org/), will be joining me this Wednesday to kick off the NightHacking Tour on a live video stream.  This is a chance to watch James live and interact with him via the social stream (via UStream or by tweeting with #nighthacking) as we chat, hack, and discover some of the things he has been working on in his new gig at Liquid Robotics.

You can sign up for the event on the NightHacking UStream site here:
http://www.ustream.tv/channel/nighthacking

We will be starting the stream at approximately 11AM PST on Wednesday, October 24th, and keep it live until we run out of interesting things to chat about with each other or the virtual audience.

This is also the start of the NightHacking Europe Tour, which will include dozens of interviews/coding-sessions throughout Europe for the next 3 weeks leading up to the Devoxx conference in Antwerp Belgium.  All of this will be live streamed from different countries as I tour around Europe via motorcycle.

So come join me online for an exclusive hacking event with James Gosling, and follow the journey as I trek across Europe!

Welcome to Day 3 of the JavaFX in Spring blog series. In this post we are going to finish off the Customer Data application by taking advantage of the Spring Security APIs on the client.

It took a little bit of hacking, but I got a GitHub project put together with a straightforward JavaFX Maven build (details on this in a future post) to run everything. Please give the full project a view and run it from source so you can experiment with the application as you read this post:

Browse Project on GitHub

For easy reference, you can flip to any of the blogs here:

• JavaFX in Spring Day 1 – Application Initialization
• JavaFX in Spring Day 2 – Configuration and FXML
• JavaFX in Spring Day 3 – Authentication and Authorization

Since my last post I made it out to two additional user groups in Texas, and had a great time speaking at both:

On the left is the Austin JUG, which is a large, well-established user group and on the right is the Houston JUG, which had a unique venue with personal monitors for all the attendees (this would be a great setup for a lab in the future!)  I posted the talks on Hacking JavaFX with Groovy, Clojure, Scala, and Visage and JavaFX 2 – A Java Developer’s Guide to SlideShare so they can grab the full presentation decks.

Getting back to the JavaFX in Spring example, in the last blog we covered Spring configuration of a JavaFX app to modularize the screens. As a simple example we did an error dialog to show how FXML ties in, but now let’s create a login page to demonstrate using Spring Security for Authentication.

The login dialog was created visually in SceneBuilder and the final version ended up looking like this:

(Since the first post I added in a few convenience hyperlinks for logging in as an employee or a manager)

And the controller code is as follows:

public class LoginController implements DialogController {
    @Autowired
    private AuthenticationManager authenticationManager;
    @Autowired
    private ScreensConfiguration screens;
    private AutowireFXMLDialog dialog;

    public void setDialog(AutowireFXMLDialog dialog) {
        this.dialog = dialog;
    }

    @FXML
    Label header;
    @FXML
    TextField username;
    @FXML
    TextField password;

    @FXML
    public void login() {
        Authentication authToken = new UsernamePasswordAuthenticationToken(username.getText(), password.getText());
        try {
            authToken = authenticationManager.authenticate(authToken);
            SecurityContextHolder.getContext().setAuthentication(authToken);
        } catch (AuthenticationException e) {
            header.setText("Login failure, please try again:");
            header.setTextFill(Color.DARKRED);
            return;
        }
        dialog.close();
        screens.showScreen(screens.customerDataScreen());
    }

    @FXML
    public void employee() {
        username.setText("employee");
        password.setText("lol");
    }

    @FXML
    public void manager() {
        username.setText("manager");
        password.setText("password");
    }
}

The important part for authentication is taken care of in the login method. This grabs the username and password from the respective fields and creates a new UsernamePasswordAuthenticationToken. To force authentication to take place immediately, we get autowire a reference to the Spring AuthenticationManager and call the authenticate method. If the user exists in our credential store the method will succeed, otherwise it will throw an AuthenticationError we catch in the enclosing try block.

For the purpose of this example we are using a local authentication store in the Spring XML config. You could easily hook up to an LDAP server or your chioce of authentication engines, but this makes the sample app we are building self contained. Here is the Spring config XML:

<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:security="http://www.springframework.org/schema/security"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
             http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-3.1.xsd">
    <security:global-method-security secured-annotations="enabled"/>
    <security:authentication-manager>
        <security:authentication-provider>
            <security:password-encoder hash="plaintext"/>
            <security:user-service>
                <security:user name="manager" password="password" authorities="ROLE_MANAGER"/>
                <security:user name="employee" password="lol" authorities="ROLE_EMPLOYEE"/>
            </security:user-service>
        </security:authentication-provider>
    </security:authentication-manager>
</beans>

This sets up two different users and two roles. One is our manager who will have full access to the system and a laughably weak password, and the second is the employee who will only only have access to create new customers, but not delete. We are going to take advantage of these roles to secure the customer creation and deletion routines using annotation-based authorization.

Now that annotations-based configuration is setup, you can secure methods in your application by simply adding an appropriate annotation to it as shown in this code snippet from CustomerModel:

    @Secured("ROLE_MANAGER")
    public void remove(Customer customer) {
        restTemplate.delete("http://localhost:8080/crm/customer/" + customer.getId());
        customers.remove(customer);
    }

Any time this method is called, you will get an exception thrown that will prevent that method from getting executed and can be caught to give good user feedback, such as an error dialog:

To finish off the example, here is a screenshot of the completed example that includes a JavaFX Table for displaying elements that are pulled back from the server using the Spring RestTemplate API:

And again, you can find the full code available for download here:
Browse Project on GitHub

Now that I have shown you how you can take advantage of Spring in your JavaFX applications, it is only fair to point out some of the shortcomings you may encounter:

• Jar Explosion – I tried to be minimalistic in my inclusion of dependencies, but still ended up with dozens of jar files for this example application. This may be an issue if you are deploying to resource constrained devices or over a thin network pipe, but for packaged applications should not be an issue.
• All Permissions Required – Since Spring makes heavy use of aspect-oriented programming (AOP) libraries that manipulate bytecode, you won’t be able to run this application in the Java sandbox. The best approach is to request all permissions and code sign your application so the end user just gets prompted once.
• AOP Glitches – In your own applications you will trip across various little quirks with AOP and bytecode manipulation that can make client programming quite hazardous. For example, if you put an @Secured annotation in a UI class file loaded in the main thread, you will get a ClassCastException on the proxy. It is possible to get the target class out like this, but it is nefarious enough that it bit me in a live-coding presentation.

Hopefully you have learned a little bit through this tour of JavaFX and Spring integration. I would love to hear what other folks have been doing to integrate these technologies in the comments section below.

Welcome to part 2 of the JavaFX in Spring blog series. Yesterday I talked about some of the advantages of using Spring in client applications and showed how to initialize your application. For easy reference, you can flip to any of the blogs (as they are published) here:

• JavaFX in Spring Day 1 – Application Initialization
• JavaFX in Spring Day 2 – Configuration and FXML
• JavaFX in Spring Day 3 – Authentication and Authorization

Today we will dig into the configuration in more detail, covering details on how you can handle FXML-based UIs. But before we get into all that work, a short aside about the San Antonio Java User Group I met earlier tonight.

It was a great user group to speak to with lots of very enthusiastic (and sharp) folks. I lightly covered the topic of Spring and JavaFX integration, and when I asked, almost everyone in the room used Spring in their day jobs. Here is a quick photo I snapped of the group after the presentation:

I am not going to embed the entire presentation, but as promised, here is the full slide deck for reference.

Now, back to the Spring configuration example, we are building out. Here is what the ScreensConfiguration class looks like for my sample Customer application:

@Configuration
@Lazy
public class ScreensConfiguration {
    private Stage primaryStage;

    public void setPrimaryStage(Stage primaryStage) {
        this.primaryStage = primaryStage;
    }

    public void showScreen(Parent screen) {
        primaryStage.setScene(new Scene(screen, 800, 500));
        primaryStage.show();
    }

    @Bean
    CustomerDataScreen customerDataScreen() {
        return new CustomerDataScreen(customerDataScreenController());
    }

    @Bean
    CustomerDataScreenController customerDataScreenController() {
        return new CustomerDataScreenController(model, this);
    }

    @Bean
    @Scope("prototype")
    AutowireFXMLDialog errorDialog() {
        return new AutowireFXMLDialog(getClass().getResource("Error.fxml"), primaryStage, StageStyle.UNDECORATED);
    }

    @Bean
    @Scope("prototype")
    AutowireFXMLDialog addUserDialog() {
        return new AutowireFXMLDialog(getClass().getResource("AddUser.fxml"), primaryStage);
    }

    @Bean
    @Scope("prototype")
    AutowireFXMLDialog loginDialog() {
        return new AutowireFXMLDialog(getClass().getResource("Login.fxml"), primaryStage, StageStyle.UNDECORATED);
    }
}

There is a lot going on here, so let me break it down in a few bullets:

• The configuration class is annotated with @Lazy so that any bean references will only be created on demand. (Other than this, it follows the basic Spring Java Config pattern using the @Configuration and @Bean annotations.)
• The configuration allows us to set a primary stage (which we did during initialization in CustomerApp), and then display a screen in that stage by calling showScreen.
• Each screen and dialog in the UI is represented as a Bean class. Notice that some are declared as @Scope(“prototype”), which means a new instance will be created every time we use it. Without this annotation, the screen is a singleton so it will get created only once no matter how many times the method is called (such as customerDataScreen).

As you can see, with very little code, we are able to construct all the screens for the application and declare their behavior and dependencies. Most of these screens are FXML-based, although I did one screen/controller pair as standard JavaFX classes (the CustomerDataScreen extending StackPane). However, the much harder case is to work with FXML screens in Spring since JavaFX creates the controller for you, making bean configuration more difficult.

To encapsulate the logic for how to inject variables into the FXML controller, I created a small helper class called AutowireFXMLDialog. The source code for that is as follows:

public class AutowireFXMLDialog extends Stage {
    @Autowired
    private ApplicationContext context;

    protected final Object controller;

    public AutowireFXMLDialog(URL fxml, Window owner) {
        this(fxml, owner, StageStyle.DECORATED);
    }

    public AutowireFXMLDialog(URL fxml, Window owner, StageStyle style) {
        super(style);
        initOwner(owner);
        initModality(Modality.WINDOW_MODAL);
        FXMLLoader loader = new FXMLLoader(fxml);
        try {
            setScene(new Scene((Parent) loader.load()));
            controller = loader.getController();
            if (controller instanceof DialogController) {
                ((DialogController) controller).setDialog(this);
            }
        } catch (IOException e) {
            throw new RuntimeException(e);
        }
    }

    @PostConstruct
    private void postConstruct() {
        context.getAutowireCapableBeanFactory().autowireBeanProperties(controller, AutowireCapableBeanFactory.AUTOWIRE_NO, false);
    }
}

Given an FXML file url as input, it does a few different things:

• Instantiate the FXML UI and add it to the Stage.  While this implementation is oriented towards dialogs, it would be quite easy to create a version that loaded it into a reusable Node.
• Inject the view into the controller.  We do this through a DialogController interface, which can optionally be implemented by the FXML controller class to get a reference to the view.
• Autowire the controller class.  For any remaining dependencies defined in the controller, we let Spring do its autowiring magic to inject all of the beans and proxies.

So this seems fairly straightforward, but coming up with this magic formula was fraught with peril.  Here are some of the things that you might think are a good idea, but simply don’t work:

1. Why can’t I autowire in the constructor? – Context is null until dependency injection happens in this class, so you would have to pass in a reference to the context (which defeats the purpose of DI)
2. Can’t I just have Spring inject an instance to the dialog? – This seems like a good idea, but is only possible after this class is fully initialized.  For singleton beans this happens to work as long as you autowire in the PostConstruct method, but once you switch it to a prototype it fails miserably.
3. Doesn’t that parameter say “NO” autowiring? – Probably a poor choice of name by the Spring devs, it just means that you have to explicitly declare what you want wired (with the @Autowire annotation). If you accidentally use AUTOWIRE_BY_TYPE or AUTOWIRE_BY_NAME, you are in for a world of hurt, because it will attempt to autowire the reference to this dialog, which fails in the prototype case because of [2]. Same thing applies for validation (3rd parameter), which seems to think it should check parameters that are not explicitly wired even though you defined the autowire type as AUTOWIRE_NO.

So the short summary is do it my way or you will be a sad panda.

Finally, to bring this all together, here is what the controller looks like for the ErrorDialog:

public class ErrorController implements DialogController {
    private AutowireFXMLDialog dialog;

    public void setDialog(AutowireFXMLDialog dialog) {
        this.dialog = dialog;
    }

    @FXML
    public void close() {
        dialog.close();
    }
}

Notice that it extends DialogController and gets a reference to the view injected, which makes it quite easy to dismiss the dialog when the user clicks the close button. You can also access any other Spring beans simply by prefacing them with the @Autowire annotation as we will see tomorrow when we hook up Authentication in the LoginDialog controller.

The next blog will finish out this example including the full source code so you can try it yourself.  Until then, here is a small screen capture of the finished error dialog:

I spoke recently to the Spring Dallas User Group, which was a great audience, and in preparation for the talk I dusted off my Spring Framework skills (with a little help from Josh Long).  Even though Spring is primarily targeted at server-side applications, you can actually do quite a nice integration between the two technologies on the client.  In addition to the full talk (which you can find below), I will elaborate on some of the patterns for building Spring/JavaFX hybrid applications in this blog.

To demonstrate how you can structure your application in JavaFX, I am going to build out a full Customer Data application over a 3 day blog series.  For easy reference, you can flip to any of the blogs (as they are published) here:

• JavaFX in Spring Day 1 – Application Initialization
• JavaFX in Spring Day 2 – Configuration and FXML
• JavaFX in Spring Day 3 – Authentication and Authorization

And here is a small teaser shot of the application login page (the full source will be posted on GitHub on the 3rd day):

You may be thinking to yourself why you should bother learning (or applying) Spring Framework in your JavaFX applications.  I am sure there are plenty of good use cases that I haven’t even thought of, but here were some of my motivations:

• Modularizing the UI – Complicated JavaFX applications have many screens involved in the workflow, and it can be difficult to create a consistent structure for the pageflow of the application.  By taking advantage of Spring configuration and some age-old MVC patterns, you can greatly simplify this making it easy for others who maintain your application (maybe even yourself in 6 months time) to easily follow the structure.
• Authentication and Authorization – No need to reinvent the wheel for user authentication and authorization.  You can take advantage of Spring Security, the most widely used authentication system in the Java ecosystem, to also handle permissions for your JavaFX application.
• Dependency Injection – If you have UI classes with a ballooning number number of constructor parameters or mandatory setter methods, then dependency injection can help you to manage the chaos.  By taking advantage of Spring Bean dependencies and autowiring, you can have access to the model, controller, and other screens simply by declaring the relationships.

To start out with, let’s cover the “safe” way to integrate Spring Framework into your application.  Since you are not running in an application server environment, you need to manually bootstrap Spring, while also starting the JavaFX runtime.  Also, the same restrictions about making UI changes on the JavaFX Application thread apply to Spring code injected into your application, so to be safe you should always execute your code on the UI thread.

The following JavaFX Application main class meets all of these criteria:

public class CustomerApp extends Application {
    public static void main(String[] args) {
        launch(args);
    }

    @Override
    public void start(Stage stage) throws Exception {
        ApplicationContext context = new AnnotationConfigApplicationContext(CustomerAppConfiguration.class);
        ScreensConfiguration screens = context.getBean(ScreensConfiguration.class);
        screens.setPrimaryStage(stage);
        screens.loginDialog().show();
    }
}

In this example I am using annotation-based config for Spring.  This is my favorite way to write Spring applications for obvious reasons (and if you agree, please take a moment to sign my Freedom from XML Petition).

It is important to start the AnnotationConfigApplicationContext inside of the start method, because this runs all the Spring initialization on the UI thread.  While it is possible (and possibly desirable) to run the Spring startup in a separate thread, if you happen to create a new Stage, Pop-up, or modify the Scene Graph in any small way, you will get exceptions, deadlocks, or worse!  I highly recommend starting with this approach, and then selectively moving long-running operations onto worker threads if startup performance becomes an issue.

Notice that the “Bean” that we are loading from the configuration is not actually a Bean, but a special ScreensConfiguration class that contains all the UI beans.  This is a standard trick to allow lazy loading of Spring beans using Java Configuration (annotations), while letting you inject and access the beans directly.  It isn’t until we call screens.loginDialog() that the UI class will actually be instantiated.

This should be enough to get you started in initializing the Spring context in your own applications.  (In my Dallas UG talk I showed a simple media example configured entirely via Spring…  a good experiment to try yourself.)  In tomorrow’s blog I will go into detail on the ScreensConfiguration class as well as share some tricks for modularizing your UI and doing dependency injection into FXML controllers.

Until then, enjoy the presentation deck from the Dallas Spring User Group:

I did a presentation at the Agile 2012 conference in Dallas on how to do Agile release planning with distributed teams.  This is something that we struggled with at my last company since we had 300 developers split into 40+ teams in 5 different countries.

I covered a bunch of different topics that matter for facilitators of Agile planning sessions, including budget hardware for video conferencing.  While you can pay for expensive video-presence solutions from Cisco and AT&T, with clever usage of consumer hardware you can achieve pretty good results for a fraction of the cost.  For more details about hardware options for doing virtual planning sessions, my hardware guide to streaming is a good place to start.

This also was an announcement of a new version of the Apropos Portfolio Planning Tool that I did in JavaFX 1.3 and previously open-sourced.  Ravi Buddharaju, one of my former co-workers who is a great Agile coach and Java developer (and leader of the new Hyderabad JUG), did a new version of Apropos based on JavaFX 2.  It is quite a bit faster and much more stable than the old version of the tool, which speaks volumes to both Ravi’s skills and also the maturity of the JavaFX 2 platform.

For more information about the Apropos project, check out the Google code project here (we will post on the front page when the new version of Apropos is checked in):

http://code.google.com/p/apropos/

The JavaFX 2 Refcard is finally out thanks to the hard work of the folks at DZone. It is intended to be a quick getting started guide for folks new to JavaFX, as well as a quick reference for some of the controls/layouts/effects that are available in JavaFX 2. Hopefully you find it useful (or know someone who will!)

Download JavaFX 2 Refcard

The main purpose of this blog entry is to serve as a discussion placeholder and addendum for the Refcard. I noticed discussions about the Refcard showing up in some other older blog entries, so this should help consolidate the discussion to a single page.

So if you have any comments/suggestions about the Refcard, or notice any small bugs or mistakes, let me know and I will keep an updated list in this blog entry.

I just finished a huge speaking engagement at JustJava Brazil. While I have been to Brazil several times before, this was my first time speaking at this event, and it was very impressive. The entire conference is community-run, and had a very good vibe to it with lots of attendees, great content, and a perfect venue to allow interaction and hallway conversations to happen.

I ended up giving 5! talks total… probably the most exhausting conference I have done in a while, but was well worth the effort. I also had a lot of local help from Marcelo Quinta (GOJava) who translated all my talks and Rafael Alfonso (ScalaFX Contributor) who cospoke with me and also was my audience “plant” during the keynote.

Speaking of the keynote, you won’t find that talk anywhere below…  I have been getting bored of scripted talks, so Rafael helped me to have a little bit of fun with it.  You had to be there to appreciate it, but the audience had a lot of fun enjoying the ups and downs as I kept changing the presentation to meet the demanding needs of our Brazilian audience. 

Return of Rich Client Java – Brazil

This was the first talk I gave, and covers JavaFX in general.  I highly recommend trying out some of the demo code by downloading the free code bundle from our book website:

http://www.apress.com/9781430268727

The next talk was a Portuguese version of the 55 New Things in Java 7 deck that Donald Smith originally did for the EclipseCON keynote.  Everyone in the audience (me included) learned something new about Java 7 during the talk, and I guarantee that you will too!

XML Free Programming – Brazil

I did a solo version of the XML Free Programming talk that Arun and I created for JavaOne last year.  Not quite as much fun without a co-presenter, but still got lots of laughs from the audience.

Have you signed the Freedom from XML Petition yet?

JavaFX and Scala – Like Milk and Cookies – Brazil

I also did an updated version of the ScalaFX talk together with Rafael.  He added some great content about the Color Selector control that he created, and added a lot of depth to the presentation since he has been committing code like crazy to the project (think he has me beat on commits by this point).

Crazy JSRs

Finally, this is not a talk that I gave at JustJava, but rather a quickie I put together on Bruno’s request during the community JCP meeting the night before JustJava.  It was a lot of fun to do with the audience, who generated some interesting JSR ideas (several a bit too good to be considered “crazy”).  Feel free to repurpose this talk for your own user group or community sessions to have some fun.

I had a lot of fun at JustJava, but it is time to move on to some of the other communities in Brazil.  Next stop is GOJava in Goiania followed by Brasilia and Salvador.  If you are in any of these locations, feel free to ping me via the Let’s Meetup page.

This past week I had the opportunity to attend JavaOne India, and in my opinion it was even better than last year.  I was speaking together with Kevin Nilson, leader of the SV Web JUG, and he commented on what a great venue that had for the event, which was easily able to hold 2000+ attendees.

Walking around the event, you could appreciate how much passion there was for Java development in India, with a diverse group of attendees that included students, professional developers, and Java community members.  Yara Senger, who came all the way from Brazil to speak about Java home automation with jHome, was impressed with the large number of women developers attending the conference.

The session that Kevin and I gave was an updated version of our HTML5 and JavaFX talk.  Since we last gave this at Devoxx, we were able to add some exciting info about Bootstrap, which is a new JavaScript framework developed by Twitter that has surpassed both jQuery and node.js in activity.  Definitely worth a look if you are developing responsive UIs in JavaScript!

Here is the full presentation deck (which you can also download by going to SlideShare):

For the finale of the presentation, which showed a Conference Tour application that shows how simple it is to mix JavaFX and HTML5 into a single, interactive application.  The whole user interface is rendered using JavaFX including the Accordion control and the Reflection effect, while the map itself is an embedded WebView that makes use of Google Maps.  By clicking on any of the conference locations in the Accordion, it automatically centers on that application in the map showing you where you can find some of the most amazing Java conferences throughout the world!

To run the project yourself, you can download the source code and open it in NetBeans or your favorite IDE.

The code for both the JavaFX UI and Google Maps component is under 150 lines, so this is definitely something you could develop yourself.  Feel free to take the code and leverage it in your own JavaFX/HTML5 hybrid projects as a starting template, and let us know what sort of cool applications you are able to build!

I put out an April Fools’ post yesterday about joining NASA to help with exploration of the big red planet.  That post was not far from the truth…  all the details about technologies developed by NASA were 100% accurate.  Heck, even the fact that I quit my job was the truth!  The only part that was not true was the company that I will be joining.

While working for NASA to help explore Mars would be a very cool gig as well, I am joining another big red entity that you might be familiar with…

I was initially skeptical about joining Oracle, but have been won over by their commitment to moving forward the Java platform that they have demonstrated over the past 2 years.  For example:

Oracle released Java 7 on schedule in only 1 year

This is something that Sun had been unable to accomplish in the 3 years preceding the merger, and had historically struggled with.

Hudson and OpenOffice have been freed

While the community outcry around the Jenkins and LibreOffice project splits made all the headlines, the ensuing freeing of these platforms by Oracle in which they donated the code to the Eclipse and Apache Foundations, respectively, was not nearly as well publicized.

Oracle saved JavaFX 2

Sun lost touch with their developer base, and built a platform that was inaccessible to Java developers and didn’t meet the needs of business client applications.  Oracle turned this around by rewriting all the APIs in pure Java, adding a much-needed focus on desktop business applications, and shipped JavaFX 2.0 on time!

For these reasons and more, I am glad to have the opportunity to continue to drive Java forward from the inside out.  In fact, not only am I going to be joining Oracle’s Java evangelism team, but at the same time they also recruited Jim Weaver, my friend and co-author on the Pro JavaFX 2 Platform title.  So what can we infer from the hiring of two JavaFX gurus like Jim and myself?

For one, JavaFX is here to stay as a part of the Java platform.

With the 2.0 release, JavaFX finally has the performance, Java language support, and business focused controls to be a worthy successor to Swing.  This is good news to those companies who have a heavy investment in Swing, because they have a path forward to continue developing mission critical business applications on the highly robust JVM platform.  Also, with the new JFXPane component that allows embedding of JavaFX applications in Swing, it is easy to begin incorporating JavaFX elements in existing web applications.

Also, JavaFX has the potential to be a driving force in cross-platform mobile application development.

Right now you have to choose between with the limited functionality, poor usability, and device incompatibility of web-based cross-platform frameworks or the high cost of writing multiple native applications.  I had high hopes that Flash would fulfill the gap between these two approaches, but Adobe fumbled he ball.  Fortunately, JavaFX has shown great promise in this area with some impressive technology demos at JavaOne, and has the opportunity for a touchdown with a business-focused release of JavaFX 2 on mobile.

I am optimistic about the future of Java and JavaFX technology in the coming years, and in my new role will be in a good position to give all of you a front row seat.  Expect plenty of blogs, articles, demos, and the usual satiric, but realistic, developer viewpoint on the Java platform as I dig my heels in at the big red giant!

This was an April Fools’ spoof — everything is factual except the company I joined.  Read more here.

Just in the past year I lead the OSCON Java conference, wrote a new book on Android Flash, and also put out an update to Pro JavaFX 2.  A lot of rumors have been flying around about what the next big thing for me will be, especially since I just quit my job this past week!  Well, time to put the speculation to rest and announce my new gig at the NASA Ames Research Center.

“…time to put the speculation to rest and announce my new gig at the NASA Ames Research Center.”

NASA actually already has quite a bit of Java in use internally at NASA today.  You may not know that the command and control systems for many of the mars rovers, including the Spirit and Opportunity, use Java technology to send instructions to the remote robots as well as analyze the data coming back and construct 3D views for the navigation software used in the control center. After 8 years on the planet, the Opportunity is still going strong, collecting data on Mars craters and seasons, and bringing back priceless images from the red planet.

NASA is so reliant on Java technology that they are also active contributors to the open-source community.  The newer K-9 rover has even more use of Java technology, for which they developed a tool called Java PathFinder in order to identify and eliminate software errors. This is actually an open-source project that you can use in your own application development to trace through different bytecode paths and identify and debug potential deadlocks or exceptions. One of the main features is the ability to deliver not just a stack trace where the error occurred, but the entire execution path that lead to that error.

Recent advances in Java make it a great platform for doing the sort of mission-critical work that NASA needs.  Embedded Java offers a compact, reliable platform for building Java applications on a variety of hardware platforms that are efficient and robust enough to be used in unfavorable conditions such as space and planetary exploration.  The Java EE platform is the industry standard for server technology, and provides a number of reliable, fault-tolerant communication transports that can speed up and data transmission and analysis for researchers worldwide.  And the part I am most excited about is JavaFX technology, which is a modern UI toolkit for developing rich client applications that can incorporate business controls, data charting, media playback, and even 3D.

“JavaFX … is a modern UI toolkit for developing rich client applications that can incorporate business controls, data charting, media playback, and even 3D.”

So you might be wondering why NASA has so much investment in Java and not web technologies like HTML5 and Javascript…  Well, let’s imagine an alternate world where Javascript and web applications were the way we did space exploration:

Swigert: ‘Okay, Houston, we’ve had a problem here.’
Houston: ‘This is Houston. Say again please.’
Lovell: ‘Houston, we’ve had a problem. We’ve had a 404 error.’

“Houston, we’ve had a problem. We’ve had a 404 error.”

Needless to say, I am glad to be working on Java, and taking it to new heights at NASA!