Steve On Java

The long awaited early access of JavaFX on Raspberry Pi is finally out.  This is a great platform for doing small embedded projects, a low cost computing system for teaching, and great fun for hobbyists.  It only costs $35 for the Model B version with 512MB RAM, 700MHz ARM processor and I/O for HDMI, Composite, Audio, Ethernet, and 2 USB ports.

So what can you do with JavaFX on a Raspberry Pi?  A great example is the digital signage that we put together for Devoxx showing the conference schedule flying by on animated space ships:

Update: And if you are not convinced that Java is performant on the Pi, check out Rich Bair’s post on fxexperience.com: http://fxexperience.com/2012/12/javafx-on-raspberry-pi/

So if you are convinced to get started, there are 3 easy steps to get JavaFX running on your Pi:

1. Install Linux on your Raspberry Pi
2. Download and copy Java/JavaFX 8 to your Pi
3. Deploy and run JavaFX apps on your Pi

This does assume you have a Pi…  For questions about where to get a Pi, how to power it, etc., I would recommend checking out the Raspberry Pi Site.

Step 1 – Installing Linux on Your Raspberry Pi

The latest Java 8 release is hard float, which is a good thing, because it gives you better performance and the recommended Raspberry Pi build is also hard float.  Stay away from anything that says soft, softfp, etc., because it will be incompatible with the hard float JVM.

Note: Why all this fuss over floating point?  Well, low power embedded systems skip the floating point hardware to save cost (e.g. ARM Cortex M0-M3).  Fortunately the ARMv6 chip used in the Raspberry Pi has real floating point support.

To setup Linux on your SD card, you will need a Windows, Mac, or Linux desktop with an SD Card Reader/Writer.  The distribution you want is the latest Raspbian Wheezy hard float build, which is the recommended install on the Raspberry Pi download site:

http://www.raspberrypi.org/downloads

To burn the image you have a few options, which are detailed here, but basically boil down to:

• Windows: Use Win32DiskImager
• Mac: Use the RPi-sd Card Builder
• Linux: Use the dd command

Once your SD card is created, take your Raspberry Pi out of the box, pop in the SD Card, hook it up to a monitor or TV lying around your place, and plug it up to a nice usb power brick (5V 700mA or greater).

Warning: Order Matters! – If you don’t hook up an HDMI monitor before powering on the Pi, it assumes composite.  This means if the lights are flashing but you get a blank screen, you should try rebooting the Pi (by unplugging and replugging it in).

At this point, your Pi should bootup and show you the Raspberry Pi config screen.  There are some things you might want to consider tweaking here, including:

• CPU/GPU memory split – Give the GPU at least 128MB of ram so graphical heavy apps will run better (important for JavaFX!)
• Change the locale/keyboard/timezone – Default settings are for the UK, so everyone else should change these or you will be cursing at your keyboard when trying to type punctuation!
• Overscan – If your display has black bars around the edges, turn this off so you can use the full resolution.
• Expand root filesystem – It can do an online resize of your card to use the full space (default image has a tiny 2GB root partition).  Highly recommended, but expect this to take a while on a large card.
• SSH – Turn this on if you want to access your Pi over the network (this is the only way to shut down rogue JavaFX processes short of rebooting)

In the official JavaFX Raspberry Pi docs they also recommend hacking the framebuffer to be 720p in the config file (/boot/config.txt) by uncommenting these lines:

framebuffer_width=1280
framebuffer_height=720

This is not strictly required, but will give you better performance since the Pi is pushing fewer pixels.  If you are going to do this, you might also want to force the Pi to run in 720 resolution as well to avoid pixel upscaling.  Don’t try hacking the display settings unless you know what you are doing (and have an ssh terminal to login remotely in case you kill the display).  For more info about the HDMI display nodes, check out the docs here.

Step 2 – Download and Copy Java/JavaFX 8 to Your Pi

You can download a Raspberry Pi compatible Java/JavaFX 8 build here:

http://jdk8.java.net/fxarmpreview

If your Pi is hooked up to the network via ethernet you can download it directly to the device.  Otherwise copy it over using sftp (via ssh) or sneakernet (a USB key).

Once you have it downloaded, you can unzip it to a location of your choice:

sudo tar -zxvf file_name -C /opt

And then to run java use a command like the following:

sudo /opt/jdk1.8.0/bin/java -version

Step 3 – Deploy and Run JavaFX Apps on Your Pi

Almost any JavaFX desktop application will run on the Pi simply by copying over the jar file and executing it locally, with no modifications.  (The 2 exceptions to this are applications that rely on WebView or MediaView, both of which are unimplemented in the current dev preview)

A great way to get started building JavaFX applications for the Pi is to use Scene Builder to quickly put together a user interface visually, and then deploy that to the Pi.  I did this last night at the Linux Users’ Group of Davis (LUGOD), quickly putting together a sample application with help from the very astute attendees (I also learned a thing or two about linux command tricks along the way from the audience).

I posted our 15 minute application in GitHub as an example you can try:

https://github.com/steveonjava/LUGOD-Pi-Test

To run it on the Pi, build the source with your favorite IDE (or straight form the command line) and build a jar file.  Then copy the jar file to your Pi and run it with a command like the following:

sudo /opt/jdk1.8.0/bin/java -Djavafx.platform=eglfb \
-cp /opt/jdk1.8.0/jre/lib/jfxrt.jar:LUGODTest.jar lugodtest.LUGODTest

Here is a picture of the Scene Builder project and the output we got on the Raspberry Pi during the LUGOD meeting:

However, the most impressive demo is your own.  Try deploying your own JavaFX applications and leave others pointers to apps you have deployed in the comments below!

JavaOne Latin America in Sao Paulo Brazil just ended.  It was a great event that had a huge community presence, which was responsible for selecting over 50% oft the content, and supported it throughout.

This started off on Sunday with the Geek Bike ride where over 50 geeks donned bike helmets and took over the streets of Sao Paulo.  I took plenty of photos of the event, which you can find on my steveonjava flickr account, and in the geekbikeride photostream:

The event was even bigger than last year with a 50% increase in registrations.  Also, we took advantage of the newly built out wing of the Transamerica Expo Center, which afforded much more room and newer facilities for the event.

I gave my updated presentation on JavaFX and HTML5 this afternoon, including some new updates that Felipe and I made to demonstrate calling back from a JavaScript event handler to Java code.  The full code is now available on GitHub here:

https://github.com/steveonjava/javaconferencetour

And you can see the presentation I gave in its entirety on slideshare:

This was a great start to our regional JavaOne conferences, which we will have more exciting news on soon!

If you haven’t been watching the live stream of the NightHacking Tour, you have been missing out on a lot of geeky fun.

I am only 1/3 through the tour route, but I have already had some pretty amazing sessions with Java Champions, Speakers, Authors, and Java User Groups.  Here are some of the talks you might want to check out:

• Sven Reimers with a prototype JavaFX port of the NetBeans UI
• Angry nerds, JavaFX Pinball, and other geeky coolness with Toni Eppel
• Java Champion, Adam Bien, showing his JavaFX performance profiling app
• A reverse interview by Toni and Adam standing in front of my motorcycle in Munich
• Live JUG hacking sessions with the Munich JUG and London Java Community
• JFXtras and behind-the-scenes look at the JFall keynote with Tom Eugelink
• Build security exploits with Sander Mak
• Discussion of modular design with Chris and Paul at JFall
• Interview with Trisha Gee on women in computing and no-sql databases
• Chat and brainstorming with Stephen Colebourne on JSR 310 and JVM languages
• GroovyFX hacking with Russel Winder
• Interview at Ben Evans’ hood
• 1-on-1 chat with James Gosling

Just tonight I had a great session with Terrence Barr where he showed a motorized solar cell controlled via a Java embedded board. Here is the video from the session:

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.

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!