Dog fooding my app

My stopwatch app was close to being done and I was looking forward to releasing a stopwatch app that I want to use. I tested it along with a small number of trusted beta testers. It’s a stopwatch, what’s the big deal? Press the start, stop and reset buttons. Check the accuracy against a standard stopwatch and you’re done, right? Not quite. I’m really into track and field. I ran as a child and still run currently. I’m also a track coach for a great track club in Houston, TX. At a recent meet, I timed my daughter’s relay team with my new app. My heart pumped with pride as I fought the urge to tell everyone around that I wrote this app. The race started and I hit the start button when I saw the smoke, not waiting for the sound. Everything went perfectly. I timed all of the splits and looked forward to reporting the times to my fellow track coaches. There was just one little problem. I accidentally touched the reset button, which cleared the screen, losing all of the data. All of the times that I had just recorded were gone. Poof! Luckily I remembered the times, so it wasn’t a complete waste. But this exposed a problem. The app needs to confirm that the user wants to do a reset. Without it, other users would run into the same issue. Losing all of the data because of one errant button press should not be allowed to happen. To correct this, I have added a confirmation dialog. So now when the user hits the reset button, the confirmation dialog is the last line of defense against complete data loss.

Java Applets on Windows 7

Recently I was visiting a friend and we talked about doing a web application. We took a look at some sample sites and some templates for inspiration. I love applets and started talking about how cool it would be if we did the front end as a series of applets. So I proceeded to show off an applet that I did a couple of years ago that is still deployed on a client's web site. When I went to the web page, the applet didn't launch and showed errors. So I looked at the Java console and it spewed some unexpected exception that didn't make sense. I took a few minutes to debug the problem but could not figure it out. On top of that, my friend was starting to get annoyed, so I momentarily gave up.

This ordeal made me think about the poor user who has no clue what a Java console is or what to do when the applet does not launch properly. That user might never return to the applet after encountering this unrecoverable error. Could I write and deploy applets with confidence in the underlying JVM? Not with the same
confidence that I had when I tried to show my perfectly working applet. Could I do this applet as Javascript instead? Probably so, and if I did, it would be smooth and error-free.

So what was the solution? It's something that the typical user might not be willing to do. The fix is to uninstall Java and install the latest version. Once I did that, the problem went away. I hope Oracle is able to make this fix smoother with future releases of Java. Issues like this are what give applets a bad reputation.

Java Applet Background Color

Problem: How do I set the background in a Java Applet?


Background: I was accustomed to treating an Applet like a JPanel. With a JPanel, you set its background color with a call to setBackground(Color). That was fine before JDK 1.6, because it was no more than a JPanel with a few differences that allow it to be rendered in a web browser. In JDK 1.6 the Applet became a top level container, which put it on the same level as the JFrame.


Solution: Since JApplet is now a top level container, I have to treat it like one.
There are two options:
Option one:
Get its ContentPane, set the background color and build your GUI on top of it.

Container cp = this.getContentPane();
Then set the ContentPane's background color:
cp.setBackground(Color.blue);
cp.add(new JLabel("Hello content pane"));

Option two:
Build your GUI on a JPanel and make it the ContentPane.

JPanel pnl = new JPanel();
pnl.add(new JLabel("Hello jpanel");
pnl.setBackground(Color.blue);
this.setContentPane(pnl);


TSA will grab a handful if you let them

With this latest government fleece, the Transportation Safety Administration(TSA) has enhanced its body search procedures. They now have body scanning machines that take a nude picture of every person who goes through an airport security checkpoint. If a traveler doesn't want to have random TSA employees looking at their naked bodies, there's another option...the enhanced body search. TSA employees will feel breasts, butts and crotches. It brings new meaning to "Oh what a feeling!"

Why don't we hear any serious talk about boycotting the airlines? That's an option too. The airlines are allowing this to happen as well as the flying public. Too often the conversation in the media is about what rights the government is taking away and how people are going to cope with being fleeced. Very rarely is there any conversation about American citizens taking action.

I have been listening to the talking heads on this topic, but it only goes as far as how the government is going to use its power against us and how we're going to deal with it. We have the power to coerce the TSA to scale back its enhanced security screening by not flying. The airlines have to respond to their market. The government will push as far as its citizens allow.

Java NumericTextField Issues

Problem: JButton requires two clicks to execute.
Apparent Cause: Adding a DocumentListener to a JFormattedTextField

Background:
I created form inside of a JDialog. The form contained a JFormattedTextField, OK and Cancel buttons and a JComboBox. The JFormattedTextField filters text, not format it. Everything worked as expected until I added a DocumentListener to the JFormattedTextField. When that happened, I noticed that it takes two clicks on the OK button for it to execute its actionPerformed() method. Visually the JButton appeared to be clicked by displaying the "mouse over", "mouse pressed" and "mouse released" events, but nothing happened as a result of clicking the button.

I replaced the JFormattedTextField with a JTextField. To ensure that the JTextField only allows numeric text, I attached a DocumentListener to it. Since my text field needed to filter user input and not format it, this is what I should have used anyway.

Good Riddance JavaFX...not so fast

JavaOne 2010 has just ended and my love/hate relationship with JavaFX(JFX) is about to get a lot more intense. For the last year, I have been trying to force myself to learn JavaFX Script(JFXS) but it hasn't been easy. The language is a complete paradigm shift from Java. I have 14 years of experience with Java and have loved it from the first time I saw an applet bring life to static web pages. JFXS uses a completely new syntax, changes the meaning of terminology that Java developers have grown to accept and added totally new concepts to learn. Don't get me wrong, learning new concepts is part of who I am, but this was so different, I had to think differently about how to construct an application. It was weird. As it turns out, I was not alone.


Oracle must have heard my expletive filled rants about them creating a new language to do what Swing should have been empowered to do years ago. During JavaOne Oracle announced that they were going to scrap any further development of JavaFX Script and add the strengths of JFXS to Java.


Until that announcement, I was unaware that JFX and JFXS were two different things. I guess because JFXS was the only to program JFX, there was no need to differentiate between the two. Now that JFX is going to become a set of Java libraries, it will be available from Java and many of the other JVM languages. That was music to my ears. I love the power of JFX, but hate having to learn a new language to have access to that power.


So what does this mean for the future of Java GUI development?

• Don't expect any access to JFX from Java until JDK 7, which is scheduled for release some time in the first half of 2011.
• I am scrapping my two JFX books and will continue to focus on Swing.
• Since I love applets, I will follow my passion and release some real world applets. When the new JFX libraries are released, I will incorporate them into my Swing projects.
  
• It is my sincere hope that Java applets will gain a stronger foothold in the web browser wars. I think applets are superior and will support Java all the way.
  
• Hopefully Oracle will make Java GUI development more popular by using it themselves on their own web site and throughout their products.
  

The GUI is screaming for a new leader and JFX can capture this position. The real war will start next year with the release of JDK 7. I'm building my suit of Java/JFX armor right now.

Join me.

Air Dried Sack

One day I was at the local fitness center, finishing an intense leg workout. I was kinda tired and before leaving I needed to grab my bag from the locker room. So far everything was normal. My mind was set on drinking some Powerade that I had in my bag like an athlete in a TV commercial. In the locker room I heard the typical sports talk coming from a television over in the corner. I also noticed the sound of the typical hair dryer. Once again, nothing unusual. Then, out of the corner of my eye, something seemed out of the ordinary. The guy using the hair dryer was not drying his hair in the normal way. I would not have noticed this but he was doing something rather peculiar. His head was between his legs, like he was looking for his balls. I guess men look for their balls every so often, especially married men. But this guy was fiddling with his balls with one hand and had the hair dryer in the other. It took a second for my mind to register that he was blow drying his balls. It's not that I was paying attention to such a thing, but it was so weird that I couldn't help but notice.

That was over a month ago and I still have that strange sight burned into my memory.