Wednesday Mar 24, 2010

300 Episodes

We had a milestone in the podcast last week: 300 episodes. That's more than one episode per week for the 4½ years we've been doing it!
We spent our 300th episode as a retrospective, looking back at highlights over the years.

We looked up some statistics, too. The most amazing one (to us) is that we are now up to 15,000 downloads per episode! Our feedback alias has over 10,000 e-mails (not counting spam). And our discussion forum has nearly 20,000 messages at this point! Wow! Thanks for listening and participating!

(Photo by Gunnar Hillert)

Thursday Mar 18, 2010

Java Posse Roundup

I've spending the week in beautiful Crested Butte, Colorado at the Java Posse Roundup. It's the fourth year in a row, with record attendance. And as always, it's been fantastic. It's hard to explain an Open Space conference - it doesn't sound like it would work, and I was personally surprised to see how well it worked when I attended the first time. Now I simply expect it, and it always delivers. One key reason why this open space conference works so well compared to say "unconference" events attached to major face-forward conferences is that you need to be away from everything and really immerse yourself - and here up in the Rockies we certainly are isolated!

The day before the conference started we had a "Languages Dojo" day where people pick different languages they're interested and go off building something. We had planned in advance to build a JavaFX version of the "Ohm Writer", a Zen-like text editor that is full screen, has nice relaxing background music, background sounds and typing sounds. We had a great time, and made a lot of progress. Unfortunately, we spent a lot of the day fighting with git (the version control system). I'm a very happy Mercurial user, but I've had a little bit of git-envy since I know it can combine local changesets into a single changeset to be pushed to the repository. I could see myself using that a lot. And setting things up on github for collaboration was very easy. But that's where the fun ended - nothing worked, simple merges aborted, error messages were completely unhelpful, and in general we repeatedly ended up checking out new clean workspaces and hand applying changes. I liked Mercurial before but now I appreciate it even more. (I hear the guys who were doing functional programming also were ripping their hair out with git. P.S. Joel Spolsky just posted a Mercurial tutorial).

The app is functional, and more importantly we made the editor start up immediately, load images and audio in the background and gradually fade in the image as soon as it's available. We also had difficulty playing the keyboard "click" sound until we realized you don't want to just repeatedly call play() on a media player -- you have to reset it -- either setting mediaPlayer.currentTime = 0s or calling mediaPlayer.playFromStart().

We also ran into another bug -- and this is a gotcha I've seen before, so it seems useful to highlight it here: For JavaFX Strings, null and "" are the same! Therefore, you don't want to write code like this:

while ((line = reader.readLine()) != null) {
// use line

because this will terminate the loop as soon as you reach an empty line!! Be very careful about checking for nulls explicitly when dealing with Strings.

We've also had Lightning Talks in the evenings. If you're not familiar with Lightning Talks, these are very quick presentations, one after the other, on any subject, but limited to 5 minutes. Yes, with a HARD 5 minute limit. The advantage of limiting the lightning talks to 5 minutes is that it forces the presenter to really focus on the interesting parts of the subject, and if it's really not interesting, at least you're only bored for a couple of minutes! The topics this year were really great though - there was even a fire-eating demonstration!
One way to keep track of the time is to use a countdown timer. We wrote one in JavaFX last year, which displays a classic countdown timer (imported Photoshop graphics) and a sound file playing as the timer is expiring. It's available as a webstart app if you want to run it for your own lightning talks, or you can study the code.

In addition to the morning open space conference sessions, the evening lightning talks, the progressive dinners, we've had some afternoon technical presentations and coding sessions -- check out our improvised projector screen in our living room:

Tuesday Sep 09, 2008

Find Memory Leaks!

I'm back!

I'm sorry I've been quiet on this blog, but I've just taken a long vacation. It's been a few years since my last long vacation, so I really enjoyed it. On top of that, we bought a house, moved and made some home improvements, and that turned out to be a lot of work. Anyway, I've been back several weeks now and I'm back in full swing. There are a lot of things going on. I'm doing various performance and stability fixes for NetBeans 6.5, I've done some updates in the Ruby support, and I'm also working on Python support. I'll definitely be saying more about that here, soon, but I'm not quite ready yet.

While I was on vacation, a high priority bug came in that I had to look at. It was basically complaining about a big memory leak, and my code looked like the culprit. So I used our memory analyzer. I hadn't used it before, but it was unbelievably easy and powerful, so I thought I'd show a couple of pictures of how to use it here, in case any of you have worried about your own memory leaks or how to fix them.
I'll show the actual bug I tracked down, so this isn't a made up fake example.

First, get a heap dump. In my case, the submitter had produced it - but if not, with Java 6 you can just run a jmap command to generate it from a running VM (more info).

Then, go to the Profiler menu in NetBeans and invoke Load Heapdump:

After NetBeans has loaded in the dump file, you can switch to the Classes view to see a sorted view of your memory usage.
There's a filter to let you search for specific classes, but you'll typically want to go for the classes near the top anyway
since that's where you're going to get bang for your buck.

Here I'm concerned with the javascript TokenStream.LexingState objects. So I have picked a class to focus on, and then I
ask NetBeans to show all the instances of my class in the heap:

You can now pick among the various instances in the left hand window and find one you don't believe should still
be in memory. Once you select it, NetBeans will search the heap to find the referenes which point to this instance.

So, you can look at all the objects in the heap of this class, and then you can follow references within the
objects to other objects, or in the References view (on the bottom), you can follow references backwards to see
who is pointing to this object, recursively!

Now, the really good part. I'm wondering why so many of these objects are still live - how are they referenced
from the top? I can right click on the object and ask it to show me:

NetBeans will search for a while, and then show a complete path from a GC root down to my object. Now I just
need to walk back from the GC root and examine each object to decide if it's justified in holding this
reference. In this screenshot I've selected the item which was the problem. As the little red badge
shows (also described in the legend at the bottom of the window), this is a static reference.
This class had created a static map which eventually end up holding a lot of context which should have
been freed up. Best of all, in this case, the culprit wasn't mine so I was able to dispatch the
bug to another developer and go back to my vacation :)

In C, you can have true memory leaks where you've allocated memory and you no longer have a reference to it,
so the memory is truly lost. In Java, with garbage collection, there's no true leak, only "unintentonally held memory".
In other words, this feature isn't just for those of you with memory leaks (where you're running out of memory).
You can use this feature to find out if you're holding more references than you're intending to. Freeing things
up can improve your application's performance and definitely reduce its resource requirements. So please give
it a try! I know there are other tools that can help track down memory issues - I've used some in the past - but
this was unbelievably simple (and by being integrated in my IDE, the Go To Source action on references made it
really tricky to figure out WHY there were references as I was checking each reference back from the GC root).

Tuesday Jan 02, 2007

Code Tip: Statically Check Multiple Interfaces

You may think generics is all about avoiding casts in collections. However, I found a really good use for them the other day that's pretty useful.

Let's say you have a method which takes a List and does something with it.

    void doSomething(List list) {
(In my code, it's actually List<String>, but I'm trying to keep other generics out of this to motivate those of you still needing a good reason to learn them.)

In my case, I needed to iterate over the list in reverse order. Uh oh, that's going to be pretty expensive for some types of lists, and if I switch my implementation to for example a LinkedList in the future, I'd like to revisit this. Obviously, I could make my method the following:

    void doSomething(ArrayList list) {

However, using specific implementation classes rather than interfaces is frowned upon, and besides, this needlessly prevents the method from being used with other random access list. On the other hand, I would like to state in some way that this method really wants to be able to access the list elements in random order.

java.util.RandomAccess to the rescue. Lists that provide random access implement this interface. But what do I put in my method signature? RandomAccess is not itself a List. I really want to specify multiple constraints on my parameter.

This is precisely what generic methods allow! The following method declaration will accomplish what I want:

    <T extends List & RandomAccess> void doSomething(T list) {

Here we're saying that my parameter T is a generic type, which satisfies multiple constraints: it both extends List and it implements RandomAccess! You can pass an ArrayList to the above method, but not a LinkedList!

Think hard about the constraints you add. In some cases, adding a RandomAccess constraint on a method is leaking implementation through to the client - it reveals something about the implementation behind the method signature that may change later. I find this most appropriate within implementation code.

Thursday Nov 02, 2006

Using JDK 5 language features in Creator

As you're probably well aware of, there were several important releases this week. First, NetBeans 5.5 was released. This has been covered extensively by other Sun bloggers so I won't repeat the highlights here - just check it out if you haven't already.

Second, a number of add-on packs for NetBeans 5.5 were released. A pack is a cluster of plugins. One of these is the Visual Web Pack, which basically bundles all the visual web page design functionality from Creator into NetBeans. With this, you can create pages Creator style alongside other NetBeans features, such as the profiler, or the UML tool, or the enterprise XML support.

There's another big reason why even Creator users should try the visual web pack (which is in technology preview state, not a final release like NetBeans 5.5.). It offers new support for Java 5 language features, as well as Java EE 5 support. I took it for a quick testspin and thought I would show it in action here.

If you download NetBeans 5.5, and then the Visual Web Pack installer, you can create Visual Web Projects. Unfortunately, out of the box, it will only offer to create J2EE 3 and J2EE 4 projects. The reason for this is that NetBeans is only bundled with the Tomcat web container, and Tomcat is not adequate for Java EE 5 projects. Thus, the trick is to also download a Java EE 5 capable app server such as Glassfish or its cousin, the Sun Application Server. Once you've done that, and you select it as the target in the new project dialog, you are able to create a Java EE 5 project. Hopefully we'll have everything ready as a single bundle so that out of the box, you're defaulting to Java EE 5 projects and Java 5 source. Here's the configuration portion of the New Project wizard (click Manage to register additional web servers).

Let's create a simple web app which utilizes Java 5 features. It will be a simple page which lets you provide the name of a Java class, and then the methods (possibly generic) of the class are displayed. Here's what the web app looks like in the designer:

Here's the button click event handler:

Note that we simply use the error method to log messages for the page; these are all displayed in the group message component. This is a very simple way to log messages for ourself during debugging. You should always have a Message Group component, on every single page of your application, during development. This will make it immediately obvious if you have validation errors or other problems that might otherwise silently occur and leave you scratching your head.

When we run and try it with some sample data, here's the result which shows Java 5 language features in action:

The next step is to play with Java EE 5 features mixed with JSF. That will have to wait for another day; I've gotta get back to my day job, which I'll blog about soon.


Tor Norbye


« June 2016