With the trip coming up in a week, I figured it was about time to put the full event itinerary in one place. For this I created a public Nordic NightHacking Google Calendar containing all of the events along with links to sign-up.

All the events will be streamed-live, so you can participate from the comfort of your office/living-room. Some of the features I am adding this time around to make watching sessions more enjoyable include:
* Low-bandwidth option – All talks are going to be streamed at full resolution (480/720p) as well as 240p in case you are watching over a phone or low-bandwidth connection.
* Realtime chat – The social stream stuff is cute, but not the same as realtime chat, so I added an IRC-based chat option in the UStream broadcast. Feel free to use both, but I know where the hecklers will be hanging out.
* And some special guest appearances – I have a few special guests lined up for JFokus, including James Gosling and the Java Posse, so please watch out for these!

If you happen to be in Iceland, Gothenburg, or Malmo, there are free JUG events organized for all those cities; please click on the event details to register. I am working on similar events for Oslo, Copenhagen, and Tallinn, so stay tuned. Also, if you want to join me for snowmobiling in Turku, or hang out in Iceland or Tallinn on the weekend, ping me on my contact form.

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:

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. There is a new installer called NOOBS that will download and setup your Pi for the first found here:

Once your SD card is formatted and you have copied over NOOBS, 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 NOOBS installation screen. I recommend going with the Raspbian Wheezy installation (default), which will start downloading and automatically install once you select it.

After the image is copied the Pi will reboot into the raspi-config utility. There are some things you might want to consider tweaking here, including:

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!

Advanced Options:

CPU/GPU memory split – Give the GPU at least 128MB of ram so graphical heavy apps will run better (important for JavaFX!)

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.[no longer needed with NOOBS]

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)

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

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:

To run it on the Pi, build the source with your favorite IDE (or straight form the command line) and build a jar file (make sure you use the same Java 8 version on desktop that you are deploying to the Pi). Then copy the jar file to your Pi and run it with a command like the following:

Share this:

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:

Share this:

In addition to the sessions I am giving at Devoxx, I also lined up an all-star set of speakers to have interviews with at Devoxx. I will be running these Wednesday afternoon and Thursday morning (CET).

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:

Share this:

I just finished up a live session with the Munich JUG that was organized by Toni Epple. We started out with group introductions, and did an overview of JavaFX on the desktop and embedded platforms. There were lots of good questions about JavaFX support on mobile platforms, deployment of JavaFX, and real-world companies using JavaFX (but to find the answers you will have to watch the live stream):

To get here i had a nice 7 hour ride down the German Autobahn… I thought I was well equipped with my 1200cc BMW (seen below in a pic I took on the eurotunnel), but when fully loaded with luggage it had a scary high-speed wobble above 180kph. And even at that speed, I was still being passed by little minivans and audis.

Although I have to say the German roads are very nicely done. They are immaculately paved, and have very helpful electronic signs that let you know you should slow down miles before you approach an accident or construction. Even though everyone was cruising along at speeds in which crashes are fatal, you felt quite safe and in good company.

Tomorrow I will be interviewing Toni and Adam Bien, so don’t miss those live events on the NightHacking stream:

Share this:

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.

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:

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)

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:

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:

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:

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:

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:

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:

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)

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.

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:

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: