Tor Norbye's Blog

Building the Android IDE Tools

2010-11-18T17:05:00.000-08:00

Do you want to try bleeding edge builds of the Android IDE tooling? No problem. We do all the tool development directly in a public git repository. Just build it, run it, and you can see all daily progress in our review tool.

Andy Rubin recently tweeted how to build Android - and as you can see, it's easy and the instructions fit within the 140 twitter character limit. However, if you want to work on the IDE tooling itself, there are many other tips and tricks to know about. The purpose of this blog entry is to document how you can set up an environment to build the Android SDK, including the IDE support, and have everything configured such that you can run and debug the Android support directly from within the IDE.

My hope is that some of you, once you have the Android tooling up and running, will decide to look under the covers, tinker with the bits, and hopefully find and fix bugs, or even contribute features! I'll talk more about contributions in a later blog post; today the focus is on building and running the bits even if you have no intention of contributing. Even bug reports from you on newly developed features would be useful.

Setup

First, you'll need to install the prerequisites for your platform. This means you'll have git, a C compiler, etc. There are quite a few steps here, and it's all platform dependent, so I'll just point you to the official build instructions where we have detailed instructions: http://source.android.com/source/download.html . If you're on a Mac, pay particular attention to the instructions on creating a case sensitive filesystem image. When I started I glossed over that part and hurried down to the git checkout command, only to discover later that I had to start over.

One other Mac specific tip, which isn't in the main Android page yet, is that Apple's recent JDK update "broke" the Android build on Snow Leopard since the build uses JNI. The location of the JNI header file changed or disappeared with the JDK update, so you now need to go to Apple and get the developer SDK, JavaDeveloper.pkg from http://connect.apple.com.

NOTE NOTE NOTE: Xavier tells me that building on Windows is more difficult because the SDK itself doesn't build on Windows, so you may have to download a system image and then build the tools components themselves manually. Hopefully I'll be able to provide more details on this soon.

Once you have everything configured, check out the source code using the first half of Andy Rubin's tweet:

$ mkdir android
$ cd android
$ repo init -u git://android.git.kernel.org/platform/manifest.git
$ repo sync

During the repo init command, it will ask you for your name and e-mail address; these will be used later if you decide to check in changesets and upload them for review.

Build

Now you are ready to build. While you could just type "make", this is where our SDK build instructions diverge a bit.

In a bash shell, run these commands

$ . build/envsetup.sh
$ lunch sdk-eng
$ make sdk

$ ./sdk/eclipse/scripts/create_all_symlinks.sh
That will run for quite a while and build everything. It will also create a lot of symlinks to help you edit and compile files within Eclipse.

Next, configure Eclipse. We support Eclipse 3.4 and up, but we're currently using Eclipse 3.5.2 for development. Make sure you get a version with RCP support, such as the "Eclipse for RCP and RAP Developers" distribution. I'm using eclipse-rcp-galileo-SR2-macosx-cocoa. (You can use Eclipse 3.6.1 - I just tried it. However, the test project won't compile. You won't need that project to run the Eclipse support. If you're going to be making changes you'll want to have it, but for now, if you're just wanting to try the new support and don't want to install an older Eclipse, go right ahead, and skip the "tests" project in the projects-to-import list below.)

To configure Eclipse, right click in the Workspace and choose "Import...", then select "Existing Projects into Workspace". You want to import precisely these projects:

sdk/eclipse/plugins/com.android.ide.eclipse.adt
sdk/eclipse/plugins/com.android.ide.eclipse.tests
sdk/eclipse/plugins/com.android.ide.eclipse.ddms
sdk/ddms (import all 3 projects - ddmlib, ddms-plugin, ddmuilib)
sdk/ide_common
sdk/androidprefs
sdk/sdkstats
sdk/layoutlib_api

Things won't compile yet, until we finish the configuration.

Go to the Preferences panel, search for Classpath Variables, and define ANDROID_SRC pointing to the top of your source tree (e.g. the "android" dir in the tweet instructions).

Then right click on the ddmuilib project and open its properties. Go to Java > Build Path, and open the User Libraries tab. You should see ANDROID_JFREECHART and ANDROID_SWT as libraries there. These will need to be configured. For ANDROID_JFREECHART, select the library and click on Add Jars, then point to prebuilt/common/jfreechart and add all 3 jars. For ANDROID_SWT, add the 3 jars under prebuilt/common/eclipse, as well as the architecture specific version - for my Mac it's prebuilt/darwin-x86/swt/swt.jar but this will depend on your OS and architecture. (When I used Eclipse 3.6 I couldn't just add the jars from this dialog, I had to go and open the User Libraries panel and there I could define libraries named ANDROID_JFREECHART and ANDROID_SWT.)

Voila -- now all the errors in the Problems view should disappear! (There are still quite a few warnings.)

Run and Debug

The next step is to add a run configuration so you can run and debug the ADT. Hit the Run button. When it asks you what to run it as, choose "Eclipse Application".

Important: Open the Configurations panel and edit the new configuration. In particular, go to the "Plug-ins" panel, and uncheck the third or so item, "com.android.ide.eclipse.tests". If you enable it you can run into some very subtle bugs where jars from the test module's classpath are accidentally conflicting with different versions of jars in the tools plugin. I wasted nearly a day on that issue...

If you're on Mac and you get "java.lang.UnsatisfiedLinkError: Cannot load 32-bit SWT libraries on 64-bit JVM", you need to add "-d32" as an argument to the VM.

You should now be able to run the ADT - it will invoke a second instance of Eclipse, where all the Android tooling is baked in. The first thing you need to do is point the tool to a version of the SDK. Open the Preferences panel, and in the Android panel go to the text field where you can point to an SDK root. If you have downloaded versions of Android in the past, you can point to the root containing all of the different platforms here. However, you don't have to -- when you ran "make sdk" earlier you built a trunk version of the Android SDK (from here on referred to as "AOSP", which I think stands for Android Open Source Project). Therefore, you can point to your build output here -- and as you continue pulling down new changes and rebuilding the SDK, your Eclipse target will also use the latest and greatest.

To point to it, use <your tree>/out/host/darwin-x86/sdk/android-sdk_eng.tnorbye_mac-x86/

That exact path will not work for you, since it has various architecture and user names in it. So open the file chooser and drill down, first to out, then host, then your os and architecture, then sdk, and then some directory which contains "android-sdk_eng", your username and your platform. Hit OK.

After a brief pause you should now see a platform listed in the listbox in the Android panel, and it will identify itself as version "AOSP". If you instead point to officially released versions of Android, you'll see versions like "5", "6" and "7". The reason we don't use a number for the trunk version is to prevent you from accidentally building an app compiled against this trunk version, and then releasing it on the market.

Now that you have your Android versions configured, you can create a new Android project. Do New > Android Project, and in the New project dialog, you need to go and choose the AOSP platform in the platform listbox. Fill out the dialog. The only trick is that it asks you for a "Min SDK Version", and here you should again type "AOSP". You can now go and try for example the Layout Editor, by opening res > layout > main.xml.

We're working actively on the layout editor, but as you can see we could use help in lots of areas, from feature development, to icon work, to bug fixing, to bug reporting! (Again, I'll talk more about contributions in a follow-up post.)

To stay up to date, just go to the command line, type "repo sync", wait for a while, and then redo the make steps (source build/envsetup.sh, lunch sdk-eng, make sdk, create_symlinks), and reopen Eclipse and rebuild all. If you get a build error, you can wipe out the entire out folder to build from scratch, but I rarely have to do that.

You can add additional Android platforms, such that you can choose which platform to use for WYSIWYG rendering (just like you can already switch theme, orientation, etc):

This is a new feature added just in the last couple of days. It lets you target older platforms but visually work with newer platforms, and quickly switch between them to see how your layout looks on different platforms. Of course, to use this you need to point your root Android tree to an install containing multiple platforms. If you do add additional platforms, make sure you copy older platforms (android-6, android-7, etc) into the platforms/ folder of the newly built SDK, rather than the other way around. This is necessary because the directory structure changed recently.

Edit

Now that you can build and run, let's take a look at the source code. The main Eclipse project to look at is the "adt" project, which is the Eclipse plugin.

First, you can configure your editor to use our custom dictionary to help the spell checker recognize words that are in our comments but are not in the default Eclipse English dictionary. Search for Spelling in the options dialog, and add sdk/eclipse/dictionary.txt as the "User Defined Dictionary" path.

Second, if you will be doing any editing of the source code, make sure you configure your editor to use our formatting preferences and our import order. Open the Java Code Style dialog, and for the formatter, import development/ide/eclipse/android-formatting.xml . For Organize Import, import development/ide/eclipse/android.importorder . The code style for the Android source code base is document in http://source.android.com/source/code-style.html.

***

That's it! You should now be able to get the source code, build, edit, run and debug the Android IDE tools!

Android

2010-10-15T11:11:00.000-07:00

I'm now working on Android!

In particular, I'm working on tooling for Android. That means I get to work fully in open source again which I enjoyed in the NetBeans days. We use the public Android git repository and I submit my fixes into the Gerrit code review tool which is a really nice workflow tool for git; I highly recommend it.

As you may or may not know, the Android tooling is Eclipse based, so I'm learning both to use Eclipse as well as writing plugins for it. There are some things I'm missing from NetBeans, but there are also some new features I'm welcoming. I just need to rewire my motor reflexes for it all to feel natural!

In the past when I've posted NetBeans tips, many of you have helpfully listed the corresponding Eclipse (and IntelliJ) shortcuts. While I have found replacements for many of the features I'm used to, I'm still stumped with the following, so if any of you could enlighten me - either with existing keybindings or optional plugins, I would appreciate it:

Most important: How can I, via the keyboard, navigate through my matches in the Find Usages search? This was my favorite keystroke in NetBeans (and I had meant to do a code tip about it) - if you press Cmd-period, you can navigate through find usages searches, build errors, diff view differences, etc. In Eclipse there is also Cmd-period, but it only works if the Search window has focus - and it doesn't work in the Diff view. (In fact, Cmd-period doesn't work in the Search window on the Mac; I don't know why, because it's listed as the shortcut, and Cmd-period does work in the editor view to navigate parsing errors. Luckily I've found the workaround of Cmd+Shift+period which navigates backwards, so I'm using that one, but I still have to give the Search window focus.)
When I select a symbol in the editor, all the occurrences (of the same variable, class, method, etc) are highlighted. In NetBeans I could navigate through these via a shortcut. Is there a way to do that in Eclipse? (Somebody told me that I could select the text and then use Cmd-k to navigate, but that's text-search based and will jump to unrelated symbols that happen to be the same string, e.g. the same parameter name in a different function).
How can I, via the keyboard, see the light bulb text? Sometimes I get a light bulb in the editor margin trying to tell me something. I have not found a way to see what it's saying other than hovering over it with the mouse. In NetBeans, Alt+Enter would show the light bulb text above the current line as well as the quickfix suggestions below the current line. In Eclipse I know I can press Cmd-1 to see the suggestions, but it doesn't show what the warning is and sometimes it isn't obvious from the suggestions what the problem is. (For example, for an unused variable the suggestion is "Remove x").
I'm really missing the NetBeans version control view (the one which lists the "status"; all your changed, added, and removed files and made it trivial to walk through and diff them). Maybe this is just because I'm working with git and there isn't a plugin which offers that view yet?
This is minor, but when I initiate instant-renaming, it doesn't select the text, which NetBeans did, and I prefer that (so I can hit rename and type the new name). Is there a way to configure it to do that?

These are the answers I've asked some Eclipse users about and still haven't learned the answers to. One question I did ask, and eventually found the answer to is how to navigate files similar to NetBeans' Ctrl-Tab feature. The reason I'm bringing it up is that only one person finally showed me the right feature but most people didn't know about it - so if you're an Eclipse user, maybe you'll find this useful: "Next Editor". It's bound to something I can't remember in Eclipse, but I rebound the action called "Next Editor" to Ctrl-Tab (since Cmd-Tab is the equivalent application-switch shortcut on the Mac). You can press it to jump between two files - but the key thing is that when you're jumping between more than two files you can keep holding the Ctrl key after typing Tab to see a dialog of your recently edited files in most-recently-edited order. I find this more intuitive than the jump-between-editing-locations since sometimes I jump to a file, look for something (without editing) and then I want to go back.

Anyway, I'm having a great time. I love working on tools, and perhaps even more, Android!

(By the way, if there are any SWT mavens out there, I would love an answer to this question which I posed on StackOverflow. If you know the answer but don't have or want to have a Stackoverflow account, feel free to post it here and I'll link back to it.)

Next Chapter

2010-09-27T06:05:00.000-07:00

Today I'm starting in a new job at Google! I'm not sure what I'll work on yet, but I certainly have some strong preferences!

Google seems to be open to employee blogging, so hopefully I can continue writing about work related topics. And I realize I've forgotten to finish my IDE tips "series" - I have a few more tips that I planned to cover so I'll try to get around to that soon!

System.exit(0)

2010-09-24T10:01:00.000-07:00

It's time for a new adventure!

I joined Sun in 1996 and I've been here ever since -- including the Oracle acquisition six months ago. It's been a wonderful time. I've met many of the world's most talented engineers, I've had the chance to work on some interesting projects and I've learned a lot! I looked at my badge that I'm about to turn in (picture on left) and it has the original photo taken when I joined -- and I look like a kid!!

However, it's time to move on. I've chosen to take a new opportunity where I'll get to have even more fun. For now, I'd like to thank all my former Sun and Oracle coworkers for the great experiences you've given me and wish you luck with the future!

System.exit(0);

New blog home

2010-09-17T14:31:00.001-07:00

I've migrated my blog from the old Sun Microsystems blogging site (http://blogs.sun.com/tor) to this new home on Blogger. It turned out to be a bit trickier than I had hoped, and as a consequence, there are probably some broken links and some bad formatting here and there. The old blogging platform was based on Apache Roller, and most other blogging platforms don't support import of Roller archives. I first tried to simply set up an account on jroller.com, but they don't allow new users. In case anyone else is trying to make a similar migration, here are some quick notes on what I did:

I exported from Roller into a MovableType format.
I used the http://code.google.com/p/google-blog-converters-appengine/ project to convert the movable type file into a file suitable for Blogger import.
However, all the dates were broken; they all showed up with today's date. I tracked this down to the fact that the converter filter assumes the times in the archive are in 12 hour format (with am/pm at the end, and for me they were not.) So I fixed this by replacing the following line in google-blog-converters-r89/src/movabletype2blogger/mt2b.py :
return time.strptime(mt_time, "%m/%d/%Y %I:%M:%S %p")
with
return time.strptime(mt_time, "%m/%d/%Y %H:%M:%S")
The biggest challenge was dealing with the images; the blog converted okay but still referenced all my image resources on blogs.sun.com. To fix this, I first uploaded all my images to picasaweb and made them world writable. Then I looked at the page in picasaweb which shows thumbnails for all the images in the album, and I saved it. This file contains image links. Unfortunately, the images all end up with many different url prefixes, so it's not as simple as just replacing the old image prefix with the new one. I wrote a short Java program to extract all the image links, and create a map from file base name to the full url.
I then wrote a simple Java program to rewrite the Blogger import file such that it replaces all urls of the form http://blogs.sun.com/... with the corresponding new Picasaweb url using the above map. I also took the image urls from the thumbnails and removed the /s128/ portion of the url, which gets you the original image rather than the thumbnail. (Also, it turns out picasaweb insists on converting all .png images and .gif images to .jpg, so the URLs have to adjusted for those cases.)
I also did a little bit of post processing on the results; for example, I collapsed some repeated br tags that are no longer necessary, and I inserted a "This blog entry was imported and urls might be wrong"-warning at the top of each imported post.
One final tip: I discovered that a number of my images were missing. It turns out that Picasa by defaults hides small images (of which I had many) - so these were not uploaded! There are places to both go and enable these as well as adding .gif to the list of included file extensions, so handling this is easy once you're aware of the problem.

Hopefully this helps anyone else wanting to make a similar migration. I have the Java code for the image url manipulation if anyone wants it (but it's not generic so you'll need to do a little massaging for your own needs.)

Don't Use Implicit Return Types

2010-06-29T16:50:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

JavaFX, like Scala, is a fully statically typed language. However, unlike Java, it allows you to omit type declarations in many places, since it can infer it. Coupled with the fact that you can use expressions as statements, and that the last expression in a function will be the return value, this lets you write really simple and clear code.


def s = "Hello";
def len = s.length();
function product(a: Number, b: Number) {
a * b
}

The function above shows an "Implicit Return Type": The compiler figures out the return type, which in this case will be a Number, and that is the signature computed for the function.

Unfortunately, this can sometimes lead to trouble! Here's a real-world example:


public function clearSelection() {
selected = null;
}

This function clears the selection in a node. The intention of the developer was probably for this function to have a "void" return type. But that is not the return type! The last statement is an expression, an assignment, which has the type of the left hand side, which is actually a node.
So the return type here is a Node! And it could easily have leaked an implementation class too.

This may not seem like a big deal here, but what if a subclass wanted to override this function? It would try this:


override function clearSelection() {
super.clearSelection();
moreStuff();
}

And this would fail compilation, with a surprising error message:


File.fx:1: incompatible types
found   : void
required: Node
override function clearSelection() {
1 error

That's right, your subclasses will now need to deal with this return type too! If it's an implementation class, they're in trouble!

There are other reasons implicit return types are bad too. Here's a function specifying a desired padding for a node:


public function padding() {
5
}

The user may have intended for this to be a Number, but since the default is "5" instead of "5.0", the implied type here is Integer, which means that subclasses will need to round their desired padding to an integer. And this is not always a good thing - see the pixel considerations article.

For all of the above reasons, our Coding Conventions Document states that you should not use implicit types, at least not for any non-private API. That includes package, protected and public functions. However, it's a simple mistake to make. We've all made it! For that reason, to help track these down, I've created a quickfix for NetBeans which identifies and fixes these problems. Here's what happens if you look at a function like the one described above:

The light bulb and underline warns you that there is a problem here. Clicking on the light bulb, or pressing Alt+Enter when the caret is on that line, shows this info:

It's telling you that you have an implicit return for a public function, and it's offering to insert the actual, current return type of the function. It's also offering to make the function Void.

Pressing return will fix the function:

There are certain return types you cannot express in JavaFX script - such as returns including generics signatures. The quickfix won't warn about those since there is nothing you can do.

You can find the module on the Plugin Center here. Hopefully it will be as useful to you as it has been to me!

P.S. We discussed this topic (implicit return types in JavaFX and Scala) for a while on the latest
Java Posse Podcast episode.

NetBeans 6.9 Released

2010-06-17T15:04:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

NetBeans 6.9 has been released.

There are important improvements for everyone here - whether you're a Java developer, JavaFX developer, Ruby developer, PHP developer, C++ developer, ... or all of the above :-)

Since I spend most of my time writing JavaFX and Java code, by far the biggest improvement in NetBeans 6.9 for me is the JavaFX support. While there is still room for improvement, editing works pretty well now. In particular, the source code formatter works well on most source files and constructs, so I've used it to reformat some of our large and complicated source files, though to be on the safe side I've checked the diffs carefully before checking in (and turned on whitespace diffing in the version control). I occasionally have to make manual tweaks, but it's really helpful in cleaning up poorly formatted source files. And Go To Declaration now works reliably! The debugger still needs work. Apparently this needs some help from the compiler so hopefully the combination of JavaFX 1.3.1 and NetBeans 6.9.1 will address that.

One huge improvement in 6.9 is the reduction of scanning delays. In addition to performance fixes in that area, there are two life saver features:

Running is no longer blocked when a scan is in progress. Even if it's scanning, running starts immediately. This used to drive me crazy!
I can turn off some of the extra aggressive scanning! There is an option for this now, so I can turn off automatic timestamp checking and instead perform scanning manually if I should need it:

(In case it's not obvious -- I'm talking about the checkbox at the bottom of the above dialog.)

If you turn off automatic scanning, you can invoke it explicitly:

There are many other new features, and I'll get back to some of them in some other posts, but for now I'll leave you with a link:
Git Plugin compatible with NetBeans 6.9.

LCD Subpixel Rendering

2010-05-20T10:11:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

While I'm on the topic of pixels -- here's another tip. This one is both Mac OSX and NetBeans (well, Swing) specific.

Subpixel rendering, an antialiasing technique, makes text look much sharper (wikipedia article).
Subpixel rendering was added to Java 6, so the NetBeans source editor looks great on Windows and Linux provided you are running Java 6. Antialiasing was never an issue on Macs, where the JDK used its own native graphics renderer which had subpixel rendering all along - until now!!

Here's NetBeans on Linux and Windows:

Let's zoom in. Notice the "strange" colors at the perimiter of the font strokes; they look strange here but oh-so-good at the proper resolution on an LCD:

Unfortunately, when Apple released Java 6 on the Mac, they switched the default graphics renderer over from their own "Quartz" renderer to the standard JDK one. That shouldn't be a problem, since Java already renders LCD text, right? Wrong! For reasons I don't know, subpixel rendering is NOT working on the Mac with the standard renderer. Therefore, by default, NetBeans text looks blurry (because it is only grayscale antialiased) on Macs.

This is easy to "fix". Just switch the rendering back to Quartz. You can do that with the following flag, added to the netbeans.conf config file:


-J-Dapple.awt.graphics.UseQuartz=true

The -J flag just tells the NetBeans launcher that the rest of the flag is a flag for the Java interpreter, and the -D flag says set the system property apple.awt.graphics.UseQuartz to true. Therefore, in your own Swing applications you can do the same thing, just drop the -J flag.

(The config file is in a place like /Applications/NetBeans/NetBeans 6.9 Beta.app/Contents/Resources/NetBeans/etc/netbeans.conf and you would add these flags to the netbeans_default_options line.)

Here is a before-versus-after screenshot; this will only make visual sense to you if you're viewing this on an LCD screen!

The subpixel rendering text is on the left.

Here's a zoomed in view, which shows the default (non-LCD renderered text):

And here's what you get when you turn on Quartz:

I presume Apple turned off Quartz by default in Java 6 for a reason. Does anyone know what it is? The JavaFX Release Notes mention some memory leaks. I've been using the flag to turn LCD text back on since I switched to Java 6 on the Mac a year ago, and it doesn't seem to have any adverse effects for normal NetBeans usage (mostly text oriented; I don't do UML editing etc).

More importantly, does anybody know why subpixel rendering from the JDK doesn't work on the Mac since it works everywhere else? Is there a way to trick it to work with rendering hints etc?

P.S. Speaking of launcher arguments - I have one other customization too. I add -J-d32. This tells the JDK that I want a 32-bit VM. I haven't measured personally what this buys me, but I saw that Charlie Nutter recommended it for NetBeans usage, and he certainly knows his way about VM tuning parameters!

Bay Area JUG Roundup 2010

2010-05-11T06:47:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

If you live in the San Francisco bay area, I hope you can come to the Bay Area Java User Group Roundup 2010 tomorrow night! It is going to be held at the Oracle conference center, and both beer and dinner will be provided. There will be an update on the java.net migration, and the Java Posse are going to record a live podcast. Note - you need to sign up in advance so visit the event details page.

Hope to see you there!

Pixel Considerations

2010-05-10T14:10:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

Antialiasing makes lines and shapes look smooth - though sometimes at the expense of sharpness. What if you're trying to draw a horizontal or vertical line where you don't need antialiasing? You might be under the impression that if you position your shapes at round integer positions, you will avoid antialiasing.
But it's not quite that simple - so avoid trying to be smart with layout code like this:


...
label.layoutX = (width - labelWidth) / 2 as Integer;
....

The idea here is that when you're placing something in the middle you might end up with a fractional value, say 42.5, and so you added the "as Integer" to round things to a whole number to avoid introducing antialiasing.

Well, this may have exactly the opposite effect! Take a look at the following picture, which shows two rectangles. Both rectangles have a stroke width of 1.0, and one of them is positioned at a round integer, and the other one is positioned at 0.5.

Here's a zoomed in view which makes things clearer:

Obviously, the rectangle on the left is blurry because antialiasing is attempting to show the line as being somewhere in the middle between them. The rectangle
on the right on the other hand is clear and crisp because the lines overlap EXACTLY with the pixel grid the line is rendered into.

Here's the thing though: The rectangle on the left is the one that was positioned at round integers, and the rectangle on the right is the one positioned
at round integer + 0.5 !

So should you run out and ensure that all your horizontal and vertical edges are positioned at 0.5? No. The key here is the stroke width. Take a look at the following figure, where I have position rectangles with different stroke widths (1, 2, 3) and different pixel positions (0, 0.25, 0.5).

Zoomed in:

As you can see, whether you match the pixel grid perfectly depends on the stroke width and the pixel positions. This actually makes sense. Think of your pixel grid as having x coordinates at the boundaries of each pixel. In other words, "0.0" is the left edge of the first pixel, and 1.0 is the right edge of the first pixel. The line position has to be the center of the stroke. So if you want to have a line of thickness 1, then that line will run exactly through the pixel, so we must position its center at x=0.5. When the stroke width increases to 2 however, the center will be in the middle (e.g. 1), and so we should position it at a round number. And so on.

When you're dealing with large shapes this isn't a big deal. But if you're trying to paint a grid (like the one below), a pattern, or small controls (like disclosure arrows - which is how I came to look into this), it can pay off.

By the way -- on OSX there's a nice screen zoom (hold the Option key and then do a two-fingered drag on the trackpad up or down) which makes it easy to zoom in and look at the pixels for anything on the screen. But unfortunately it doesn't show pixels as square, it does more blending, so it's much harder to tell what's going on at the individual pixel level. Get an image editor which lets you zoom in with clear pixel boundaries, or even a screen magnifying lens. Here's how the builtin screen zoom looks - as you can see it's not as clear as the pixel zooms above:

UPDATE: Marius taught me in the comments that you can turn off the OSX zoom smoothing in the Universal Access options. Sweet! I can now instantly check the pixels without going to an intermediate screenshot! Thanks!

Finally: Jonathan Giles from the JavaFX controls team has been doing a great job aggregating and summarizing interesting FX articles each week -- highly recommended if you're doing anything with JavaFX.

nbgit for NetBeans 6.9 beta

2010-04-29T08:51:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

My brother was asking me for a version of nbgit (git support for NetBeans) that works with NetBeans 6.9 beta. I've uploaded one here. By the way, look at the Options wiki page, and especially the sections on Custom Actions, for useful configuration tips for nbgit.

IDE tip: Go To Implementation

2010-04-28T12:39:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

One of the best parts of using an IDE instead of an editor is "Go To Declaration". When you hold the Control key (or the Command key on Macs), identifiers under the mouse turn into hyperlinks and when you click on the hyperlink you jump to the declaration point of say the method call.
You can also just hover over the hyperlink, and a tooltip will pop up and show you the signature of the identifier - the fully qualified type name, method arguments, and so on.

But what if the thing you are pointing at is an interface? Or an abstract class? Good Java programming style dictates that you should prefer interfaces over implementation types, so your code will typically only know about the interface or abstract type, and when you jump to the declaration, you go to the boring interface method definition, rather the interesting bits in the implementation!

This is what the Go To Implementation feature is for. And I have a confession to make: I didn't start using this until recently. At the recent IDE tips roundup session, somebody asked whether NetBeans supported Go To Implementation. By instinct I went to Google and looked for a NetBeans plugin to do it, and found one. Unfortunately, it was old and only worked with older versions of NetBeans. Uh oh. Then on a whim I decided to look in the Navigate context menu in NetBeans - and lo and behold, it's right there!

And you don't need to use a context menu to access this feature. The trick is to use a second modifier key to the normal ctrl-click on the identifier! In addition to the control key (or command on Macs), also hold the Alt key (Option on Macs).

Here's how it works. First, let's say you want to go to the actionPerformed implementation. You ctrl-click the identifier:

...and that takes you into the abstract method declaration. (In this specific case, the method is in a read-only file inside a .jar file, which is why NetBeans marks the whole file in gray)

That's not what we want. Go back to the previous editor location (Ctrl-left.) This time, hold both the Control and Alt keys (or Command and Option on Macs) when you click. When you do that you get this dialog:

This dialog has focus and you can use the arrow keys to navigate and press enter -- or just click with the mouse. As soon as you pick a specific override of this method, you jump to it:

That's all there is to it. It's doubly embarrassing that I didn't remember this feature, since I should know the implementation of it very well. You see, I shamelessly lifted most of the implementation of it for the language-infrastructure work I did to support Go To Declaration in Ruby, JavaScript etc:

P.S. I've updated the wiki page with a clarification that it's built in now.

P.S.2: Until recent builds, Go To Implementation in NetBeans only worked for interfaces, not methods extending abstract classes. So use 6.9.

IDE tip: Create Build and Execution Shortcuts

2010-04-13T06:41:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

We're moving over to Oracle's mail and file storage, so I spent a couple of hours going through my old Sun home directory to see what I wanted to save. It was pretty fun coming across all kinds of old screenshots, source code and design documents for things I worked on 10-15 years ago.
I spent the first 5 years working on Sun's C/C++ development environment, and in particular the debugger. One feature I built was the ability to create custom buttons which would let you run frequent dbx commands (as well as reference builtin actions). Here's one screenshot I came across.

The CDE/Motif widgets look pretty dated

Anyway, this reminded me of another really useful feature in NetBeans: The ability to create custom shortcuts for ant targets. If you're using ant, you probably have a number of useful, extra build targets. One I find particularly useful for our setup (where we have lots of project dependencies) is to have a "just run" build target which skips all dependency checks and just runs whatever bits are there. This is particularly useful if I change something in an upstream project and I don't want any checking downstream.

Here's how you do it. First, let's say I've created an ant target to

Target ideas: Run findbugs. Run code coverage. Run an arbitrary script.

How to Write a Memory Leak Unit Test

2010-04-01T13:57:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

Unit tests are great for ensuring that your functionality is correct. But how do you make sure you don't have leaks in your code, leaks that
eventually cause your application to crash when it runs out of memory? Unit tests don't typically don't run into memory problems directly because they tend to start up, run a little bit of code, and shut down -- getting a nice fresh memory environment on each test start.

One great way to help protect yourself from uptime problems is to write leak tests. These are unit tests where you first perform some operations, then do normal cleanup, and finally you assert that the objects you were using during the operation have been cleaned up completely. In other words, that there are no references left anywhere on the heap.

Testing for leaks isn't very hard; the basic trick is to create a weak reference to your to-be-cleaned object (by constructing a WeakReference wrapping your object), then you delete all your local references to the object, then you perform garbage collection, and finally you see whether the weak reference still contains your object. This works because the weak reference is handled specially by the garbage collection system.

It turns out things aren't quite as easy as that, because garbage collectors try to be smart, and simply calling System.gc() doesn't mean it's going to actually perform a complete and final garbage collection. This means that your unit test could incorrectly conclude you have a leak, since the reference is still held.

The NetBeans team has built a really good test infrastructure for this. When I wrote unit tests for NetBeans plugins, I could simply call their assertGC method to assert that the given weak reference should be garbage collected, and it would handle the rest. (Internally, they do things like actually allocating a bunch of memory chunks to really force the garbage collection to run.)

Here's an example:


// The following unit test fragment wants to ensure that a graphics object
// which shows the current selection in the authoring tool, is cleared up after
// the user clears the selection.
view.selectAll();
Node firstHandle = /* Node showing selection highlight, lookup code here */;
assertNotNull(firstHandle);

// Now clear view selection -- then assert that all the handles have disappeared
view.selectNone();

WeakReference<Node> ref = new WeakReference<Node>(firstHandle);
firstHandle = null;
assertGC("Selection handle leaked", ref);

When you write these tests you also have to make sure you null out any local variable references you are holding right there in the test.
The above test will pass if and only if the target object, firstHandle, is properly garbage collected.

But wait -- that's not the best part. Let's say you've written a leak test, and it fails. Now what? What do you do -- make the process pause and attach a profiler and try to hunt it down?

This is where their unit test support really shines. When the unit test discovers that the reference is still held somewhere, it uses its own heap walking library to hunt down the offending reference, and dumps it out as part of the test assertion failure message!!!

Here's the output of a real leak test failure:


Testcase: testMemoryLeak(SelectionHandlesTest):        FAILED
Selection handle leaked:
public static java.util.List javafx.scene.Scene@dc8a29-$dirtyCSSNodes->
java.util.ArrayList@4ed14172-elementData->
[Ljava.lang.Object;@3c22de9e-[41]->
javafx.scene.shape.Rectangle@612e4cd

In other words, we see that there is a static list in Scene named dirtyCSSNodes which is holding on to our target Rectangle. The syntax here is that you first see the class name for the object (where a prefix of [L means it's an array-of), then its system id, then the field name - and if it's an array, the array index.

When the unit test fails, it takes a while -- 20 seconds or so for the above test -- to actually produce the above trace. But the important part is that this is only slow when the test fails. It only has to work hard when you have a leak, and you don't want to have leaks!

I've been wanting to write leak tests for the authoring tool (which is written in JavaFX), since uptime matters a great deal in a tool which deals with potentially large objects (such as multimedia assets). And I realized that there is absolutely nothing NetBeans specific about the NetBeans leak unit test support. So I went and pulled out the relevant code into a separate library. The library basically contains two parts: a .jar file which contains the INSANE heap walking library, and a second jar which contains the assertGC() unit test assertion method and supporting infrastructure.

I have extracted this into standalone pieces (outside the NetBeans infrastructure) so you can get the bits easily - download leaktests.zip, then add the two jars in there on your test classpath and call assertGc() and assertSize() from your tests as described above. Here's the basic skeleton for all leak tests:


// (1) Create your objects
// (2) Look up the object you want to ensure gets cleaned up later:
Foo foo = // code to get foo
assertNotNull(foo);

// (3) Call your cleanup code which is supposed to free everything

// (4) Create a weak reference to your object reference, and null out
//   your reference
WeakReference<Foo> ref = new WeakReference<Foo>(foo);
foo = null;
assertGC("Foo leaked", ref);

All I've done is extract NetBeans code written by others so I've kept the licenses the same as for NetBeans. All credit goes to the author of INSANE, Petr Nejedly -- and to the authors of the memory assertion stuff in NbTestCase.java. All the source code for INSANE and NbTestCase are in the NetBeans mercurial repository.

In addition to assertGC, there is also assertSize(). This method can be used to ensure that the transitive size of an object graph is below a certain threshold! This can be good for writing tests to not only ensure that you don't have leaks, but that your data structures are of the rough expected size so you don't need excessive amounts of memory. There are more details on this on the INSANE home page.

One special note on JavaFX: The above leak isn't actually a leak; it is a deliberate optimization of the scenegraph, and the reference will be cleared up after the next scene pulse completes. Therefore, for unit leak tests, in addition to actually nulling out the weak references, you also want to run through a scene pulse as well. One really hacky, implementation-dependent and unsupported way to do that is to call scene.$scenePulseListener.pulse();. You probably want to isolate that in a utility method such that you can update it in one place when it needs to change...

Finally, note that I built this on JDK6. If there is interest perhaps we could create a wrapper project for this on Kenai or java.net, where people can also create say a Maven binary for this, a JDK 5 version (there is nothing JDK6 specific so it just needs a recompile, but I don't have JDK5 on this Snow Leopard Mac), etc. Hope you find this all as useful as I have!

IDE tip: AST-based Selection

2010-03-30T03:45:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

AST-based selection is a feature which lets you select the surrounding "block", based not on syntactic clues (such as braces and parentheses, as is offered by practically all editors), but based on the parse tree created by the compiler (or the "AST", for abstract syntax tree).

In NetBeans, there are two complementary actions to deal with AST selection: Select Surrounding and its reverse. They have other names which I can never remember, but the keybindings are as follows:

Select surrounding block

Mac: Ctrl-Shift-. (period)
Windows/Linux/Solaris/Others: Alt-Shift-.

Reverse:

Mac: Ctrl-Shift-, (comma)
Windows/Linux/Solaris/Others: Alt-Shift-,

On my U.S. keyboard, the comma and period keys are marked with "<" and ">" for the shift key which is somewhat reminiscent of blocks.

These two actions cooperate and are stateful: they remember the original caret location such that you can "go back".
Here's how it works. You want to select something surrounding the caret, say the whole method. In that case you just
hit the surrounding action. With your fingers holding ctrl and shift you hit dot -- once, twice, bam bam bam. If you do it
quickly you might "overshoot" and go one too far and select say the whole class instead of just the method. If so just press
comma and voila, it goes back one step down the selection hierarchy you just came up.

This makes this a very quick way to select code blocks -- no more need to grab the mouse and try to hit exactly the selection
boundaries between characters.

Here's an example of where this comes in useful. I sometimes remove long expressions from method call arguments by pulling it
out as a separate variable. Here's my call, and I want to extract the whole Math.min expression.
First I move the caret anywhere within that expression:

Then I press Alt-Shift-. (or Ctrl-Shift-. on Mac):

One more time:

Let's pretend I was doing it quickly and hit it one extra time:

That's too far, so I press comma (with the modifier keys still pressed):

In practice (and with practice) this is done very quickly, faster than I can
accurately hit both ends of the expression with a mouse drag. And to finish
out the example, let me show a couple of more things related to the task.
Notice how there's a light bulb in the left hand side margin of the editor.
That tells me there are associated quick fixes. I press Alt Enter,
and the quick fix dialog is shown:

I choose "Introduce Variable" and press Return. This gives
a dialog where I can choose the variable name (and whether to replace all occurrences
when applicable). It suggests "min" since that's the function
name of the expression we're extracting.

Just press Return to apply the refactoring, and we've pulled out the argument
expression:

I just pressed return and got the default name. Then I realize that this may
not be a great name. What is that last parameter again? I can place the caret
somewhere within the last argument and press Cmd-P (or Ctrl+P
on other platforms) to get NetBeans to "Show Method Parameters".

Let's rename it to length instead. Press Ctrl-R (all platforms) to
apply rename refactoring, which (because this is a local or private variable)
will have "instant rename" applied where your edits are applied immediately
for every keystroke:

Just type the new name - notice that all the boxed expressions are edited synchronously.

Using AST-based selection to identify code blocks to extract as variables or methods
is useful, but it can be used in other ways as well. Let's say I want to add
a second validation step to this function. First I select the code block using
AST selection:

NetBeans has a keyboard command for duplicating the current line: Ctrl-Shift-Down
(and on Mac, it's Cmd-Shift-Down.) Note that when you have a selection, this
duplicates the entire selection. So all we have to do now is apply the duplicate command
and we've got a second if clause we can just tweak to whatever it is it needs to do.

AST based selection should be available in nearly all editor types in NetBeans.
In Ruby, JavaScript, Python, etc it also handles documentation
blocks well - so if you apply select surrounding in say a Ruby comment, it will first select
the current line, then the whole documentation block, then outwards in the AST hierarchy.

Hope you find this helpful. If there are Eclipse or IntelliJ readers who know corresponding
keybindings in Eclipse, feel free to leave a comment so others can find it easily.

IDE tips

2010-03-25T06:45:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

One of the sessions we had at the Roundup was one entitled "IDE tips and tricks". We basically sat there with our laptops and did a show & tell of various "hidden" IDE features we knew about to help productivity. There were Eclipse, IntelliJ and NetBeans users there - and even some advocacy for Vim :) We discovered pretty quickly that this would not make for compelling listening, so we just turned off the recorder.

One thing I discovered (and which I saw during our languages coding dojo day as well) is that a lot of people don't use many of the productivity boosters. Therefore, I thought I'd bring some of these up here. Since I've been intending to start blogging more again, I'll make this a regular "column".

To kick things off, I'll just point to an old blog entry which is still relevant: Hippie Completion. Learn to use Ctrl-K while editing, it will be worth your while. (Eclipse has this too as of Eclipse 3.1; I believe it's bound to Alt-/).

Transparent windows on Linux

2010-03-25T01:55:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

JavaFX makes it easy to create non-rectangular windows -- just set a StageStyle.TRANSPARENT on your stage.style.
We use rounded corners on our popup menus, and we also have a non-rectangular and alpha-blended splash screen.

The other day I was checking how the cursors were looking on different platforms, and imagine my horror when I discovered how our new splash screen and rounded menus looked on Linux! Here they are -- as you can see you end up with white rectangles around the supposed-to-be-blended areas:

That looks.... craptastic!

Historically, the JDK didn't support alpha blended windows on Linux. However, that was added a while ago (I'm not sure exactly which version, but I think it was JDK 6 update 14). It turns out that the FX code which initializes the native frame for the stage does not do conditional checking for this; it simply turns off transparency on Linux. Fortunately, there's a System property you can set to force it to respect the transparency flag. You would obviously only do this if you know you are running on a JDK which supports transparency. And that's easy!

In your startup code, do something like this:


if (Utils.IS_LINUX and Utils.jdkAtLeast(1, 6, 0, 14)) {
java.lang.System.setProperty("javafx.allowTransparentStage", "true");
}

There are a couple of utility methods here that are simple - just looking at some system properties to determine whether we're on Linux and whether we're on a particular version of the JDK or higher (if you run on non-Sun/Oracle JDKs you may want to check for that as well).


public def IS_LINUX = osName.contains("linux");
public def IS_MAC = osName.contains("mac");
public def IS_WINDOWS = osName.contains("windows");
public def IS_SOLARIS = osName.contains("solaris");

/**
* Is the version of the running JDK at least major.minor.micro_update?
* In 1.6.0_18 macro=1,minor=6,micro=0,update=18
*/
public function jdkAtLeast(macro: Integer, minor: Integer, micro: Integer, update: Integer): Boolean {
def runtimeVersion = java.lang.System.getProperty("java.runtime.version");
def pattern = java.util.regex.Pattern.compile("^(\\d)\\.(\\d)\\.(\\d)_(\\d+)-");
def matcher = pattern.matcher(runtimeVersion);
if (matcher.find()) {
def currentMacro = Integer.valueOf(matcher.group(1));
def currentMinor = Integer.valueOf(matcher.group(2));
def currentMicro = Integer.valueOf(matcher.group(3));
def currentUpdate = Integer.valueOf(matcher.group(4));
if (currentMacro < macro or currentMinor < minor or
currentMicro < micro or currentUpdate < update) {
return false;
}
}

true
}

With that modification at startup, we get much nicer results:

P.S. Yes, there's a JIRA issue tracking this to be automatically done by the platform, RT-4797.

P.S.2. This is for desktop; I'm not sure this code is mobile-safe.

300 Episodes

2010-03-24T13:51:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

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)

Java Posse Roundup

2010-03-18T16:20:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

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:

Using Mercurial over ssh without typing the password

2010-03-01T13:16:00.000-08:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

We're using Mercurial. Our release engineering servers run web servers, so we can browse our repositories, just like the public NetBeans ones at http://hg.netbeans.org, and pull down new changesets anonymously. However, for authentication purposes, we also use ssh, so all pushes to the repository has to go through ssh.


$ cat .hg/hgrc
[paths]
default = http://our.server.sun.com/our/repository
default-push = ssh://our.server.sun.com//our/repository

(P.S. Notice how there are 2 slashes in the SSH path and only one in the http path - if you forget about that Bad Stuff(tm) happens.)

This means that whenever I pull (or determine incoming changes via hg incoming) it executes immediately, but whenever I want to push (or determine outgoing changes), I need to supply a password. And let's just say typing my password is not easy, since the password requirements at Sun (and shortly, Oracle) are really strict - no nice, short and simple passwords here!

I've been putting up with it for a year now - after all, it's just a couple of seconds here and a couple of seconds there - but I knew it should be possible to fix this, since back in my hardcore Solaris days I had all this stuff configured correctly via the ssh key agent so that I could ssh from one account to the next. On the other hand, I've googled it (mercurial + ssh) a couple of times, and the information I've found has always been for doing more complicated things (1,2) than the simple authentication setup I wanted. So I just put it off.

I decided to bite the bullet and look into configuring it - and it was really trivial. I'm bummed I haven't tried earlier! I thought I'd write this up in case it helps anyone else in a similar situation.

The reason it's trivial, is that it turns out there is nothing specific about using Mercurial here. This is actually a case where Googling something was harmful! If I had just tried it, instead of searching for a recipe and getting confused, I would have had this set up a long time ago! Hopefully this blog entry will help anyone searching for "hg ssh passwords" ! Anyway... You just need to ensure that you can ssh directly into the system you are trying to push to, and if you can do that, then mercurial can do the rest. And this setup is easy and well documented.

First, you need to generate a local key.


$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/tor/.ssh/id_rsa):
Created directory '/Users/tor/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/tor/.ssh/id_rsa.
Your public key has been saved in /Users/tor/.ssh/id_rsa.pub.
The key fingerprint is:
... (omitted) ...

Next you need to copy this file to the server and call it ~/.ssh/authorized_keys. Actually, that file may already exist and you really want to append to it, not replace it. So first ensure the directory exists:


$ ssh tor@our.server.sun.com mkdir -p .ssh
Password:

And finally copy your authentication key over to the server:


$ scp .ssh/id_rsa.pub tor@our.server.sun.com:.ssh/authorized_keys
Password:
id_rsa.pub   100%  422     0.4KB/s   00:00

That's it! Now try logging in again:


$ ssh tor@our.server.sun.com

On my Mac, this actually pops up the system authentication dialog:

Not only can I enter my password in the dialog, but I can tell it to remember this key in the keychain, and from now on, the system supplies the password to ssh when it wants to log in to hosts.


$ ssh tor@our.server.sun.com
Identity added: details omitted
Last login: Mon Mar  1 19:22:18 2010

And now, the whole point of this exercise -- I can run "hg out" and "hg push" (as well as scripts which operate over multiple mercurial repositories) without the need to type that annoying password again. On the other hand, how will I remember it now that I'm not repeating it like a mantra dozens of times per day?


$ hg out
comparing with ssh://our.server.sun.com//our/repository
searching for changes
no changes found

P.S. Here's a copy of my own authentication keys in case that helps you configure your own system. Please don't use these to log into our system.

How to Render a JavaFX Node into an Image

2010-02-11T15:12:00.000-08:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

Sometimes you want to render a Node tree into an Image. For example, you may want to do it for performance reasons (such as this example), or you may want to create thumbnail views, or perhaps you want to create a nice drag & drop effect where there is a ghost image of the object being manipulated showing both the current position (the real node) and its target position (its image).

There are some solutions posted for this, but they rely on pretty deep ties to AWT and scenegraph internals. There isn't a way to do it using public APIs yet, but here is a simpler solution. This uses a method on Scene to render the scene to an image, so the trick is to temporarily remove the Node from its current location in the node hierarchy, place it in a new Scene, render the image and put the Node back. This is all pretty simple - you just have to take care of some minor details - like the fact that the scene render will render from (0,0) to the size of the scene bounds, rather than from minX to maxX and minY to maxY. So, we have to add a reverse Translation to place the image back. There is also a problem that the scene render will truncate the bottom and rightmost pixels, so we need to explicitly set the scene size and padd it by 1. And finally, with CSS in the picture we want to duplicate the stylesheet reference from the Node's scene in the render scene, and we also need to preserve the style context. (There are more issues here around CSS; it is a key new feature in JavaFX 1.3 and central to the controls, and there are implementation aspects here for when the CSS phase is running, and it turns out currently the layout styles stay intact - they only get recomputed on the next layout pulse - so this all works beautifully. But the implementation is changing a lot these days so this may need tweaking before this ink dries!)

The only limitation here is that we need to be able to move the Node to render it - which means you cannot render any Nodes that are bound to its parent, e.g. you have a parent group whose content property is a bound sequence including the Node.

http://piliq.com/javafx/?p=1108
http://forums.sun.com/thread.jspa?threadID=5392972

Note - NOT official APIs - much cleaner.
Limitation
Couple of necessary tricks: must set scene bounds, and shift it to (0,0); scale

def platformImage = scene.renderToImage(null);
image = Image.impl_fromPlatformImage(platformImage);

Anyway, I wrote some code to do this today. This doesn't only render the node; it also has the possibility to scale the image if its width or height exceeds a certain number. We do that because in the authoring tool we show a little preview of the selected component, and this uses the render to node facility.
(Screenshot here)

My Test Environment

2010-02-11T13:02:00.000-08:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

Last year I documented my setup for running unit tests on my Mac. The solution relied on a quirk of how the window system on the Mac worked. And unfortunately, when I upgraded to Snow Leopard a few months ago, the solution stopped working.

However, after trying a few things I've found a new setup which works -- and thanks to some other improvements I now have a better setup than ever!

In short,

I run the unit tests via Hudson, the continuous integration server. The tests are running on a different account on this Mac, such that
the UI tests never interfere with my work - no focus loss, no windows popping up, etc.
I use a special Hudson plugin to filecopy my source tree to the build server repository, such that I don't have to check in the code I want to run tests again.
Since Hudson is running locally it has access to my audio, so I have it speak when the build is done (and whether it succeeded or failed) so that I know immediately whether to push my changes or investigate the build or test failures.

The tri
AUDIO

How to determine the JUnit 4 current test name

2009-12-11T01:44:00.000-08:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

In my unit tests I often want to know the name of the test that is executing. For example, I often want to have the golden file (expected test output) computed automatically from the testname. As another example in my JavaFX testing, I often generate screenshots inside failing tests and it's useful to name these screenshots by the failing tests.

In JUnit 3 this was simple, since your testcases would extend a builtin JUnit class which had a method you could call to return the current test. However, with JUnit 4 that's no longer possible. I've googled and found the "correct" way to do it - using a special @RunWith to run the test class - but I find that solution unsatisfying. My utility methods which are invoked to read golden files and screenshot etc are in one place and I now have to decorate all my tests. Besides, I already have a @RunWith annotation on my tests because I want to run them on the event dispatch thread so I have a special test runner for that.

So, I've found a better way to do it. Better for me I mean - this may have problems and limitations I'm not aware of, but for all of my tests this worked wonderfully, and doesn't have the @RunWith requirements (though note that I don't do multithreading in my tests, other than invoke them on the event dispatch thread, so if you try to call this from a thread that didn't invoke the test it probably won't work):


public static String getTestName() {
// Try to find a method on the stack which is annotated with @Test -- if so, that's the one
StackTraceElement[] elements = new Throwable().fillInStackTrace().getStackTrace();
for (int i = 1; i < elements.length; i++) {
StackTraceElement element = elements[i];
try {
Class clz = Class.forName(element.getClassName());
Method method = clz.getMethod(element.getMethodName(), new Class[0]);
for (Annotation annotation : method.getAnnotations()) {
if (annotation.annotationType() == org.junit.Test.class) {
return element.getMethodName();
}
}
} catch (NoSuchMethodException ex) {
} catch (SecurityException ex) {
} catch (ClassNotFoundException classNotFoundException) {
}
}

// Just assuming it's the calling method
return elements[1].getMethodName();
}

As with most of my test utilities, it's a public static method living in a class called TestUtils, which I statically import from my test cases such that I can simply reference the test name getter like I would in the JUnit 3 days:


import static org.junit.Assert.*;
import static my.package.name.TestUtils.*;

/* ... */

screenshot(scene, getTestName());

By the way if you're using JavaFX you might be interested in the screenshot utility method. It's really simple:


public static File screenshot(Scene scene, String fileName) throws Exception {
BufferedImage image = (BufferedImage) scene.renderToImage(null);
if (!fileName.endsWith(".png")) {
fileName = fileName + ".png";
}
File file = new File(getScreenshotDir(), fileName);
file.createNewFile();
ImageIO.write(image, "png", file);
return file;
}

(where obviously getScreenshotDir() returns a File folder where you want your screenshots generated. A decent default implementation is return new File(System.getProperty("java.io.tmpdir")); ...)

JavaFX Coding Conventions

2009-11-08T12:29:00.000-08:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

I've been writing a lot of JavaFX code over the last year. After some tweaking I've arrived at a style that I like a lot. I notice that even on my team there are some variations in how people format their code, so I thought I would document what I like in case this helps others get started. (I did a quick google search and didn't find any JavaFX coding convention documents anywhere. The closest thing I found was a blog entry, but while it contains a lot of good advice, the style it recommends does not match the practice of the JavaFX team (or the Sun Java style) either). Therefore, I thought I would document what I consider good JavaFX coding conventions.

Rather than post them here in a blog entry, I placed them in a Wiki page such that they can easily be improved and kept up to date as I get feedback and in case I change my mind :)

You can find the coding conventions document here:

http://wikis.sun.com/display/JavaFxCodeConv/Home

P.S. I will be speaking at Devoxx in Antwerp, Belgium next week! Hope to meet some of you there!

NetBeans 6.7.1 is out - with JavaFX 1.2 support

2009-07-28T11:03:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

NetBeans 6.7.1 was released yesterday, which in addition to a number of important bug fixes in various areas, also now includes support for JavaFX.

It looks very promising; the biggest problems I mentioned a couple of months ago are fixed. I no longer get any bogus or stale error messages. And the preview pane seems to work - I'm not getting exceptions left and right. Also, the preview panel is docked into the navigator area - that seems like a good place for it.

Code completion and import management works as before - which means it might be a little surprising (see my old blog entry for tips), but it works.

Unfortunately, my two other pet peeves are still there: No toggle comment, and no mark occurrences jumping - which is extra problematic since there's no Find Usages for the JavaFX support. I took a quick peek at the sources, and adding it is trivial - so I submitted a patch.

In the meantime, you can download this .nbm plugin file and install it via Tools > Plugins if you want to get these two features. Cmd-/ to toggle comments, and Ctrl-Up/Down to jump between the occurrences in the current file. Note that I couldn't create a separate plugin to do this - I hacked the existing JavaFX editor support. That's because the mark occurrences feature needs to access a method which is package private (and I didn't want to mess around with reflection - I can't spent time on this). This unfortunately means though that you are using a hacked version of the FX editor module. If they release patch updates later you'll be replacing this functionality. But hopefully by then they will have applied the patch!

I noticed by the way that all the source code for the NetBeans JavaFX plugin is available right there in the public NetBeans Mercurial repository - so you can not only grab the source code and build it yourself, but you can fix and contribute patches to make the support better. I want a good JavaFX source formatter! Actually I'll even settle for just a simple indenter. Please, pretty please? P.S. I see that there is already a code formatter class in there - I added a breakpoint and stepped through it a bit but I couldn't see anything obvious, and I unfortunately can't spend any time on this, so hopefully somebody else can step up to the plate?

Back from Vacation

2009-07-06T06:14:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

I'm back from a nice but short vacation. We didn't have a detailed itinerary - we just took one day at a time and decided where to head next. We spent several days in the old Gold Rush country in the Sierra foothills - there were many things to see, such as museums, mines and caverns, and a preserved whole gold rush town with original buildings, a no-cars main road and all employees wearing authentic clothing. From there we visited the central coast and went to several of the original Missions, and ended up seeing the 4th of July fireworks from the beach in Santa Barbara. While I was gone I see that NetBeans 6.7, and Virtual Box 3.0 have both been released. Both should help me as I get back to work...

New iPhone software - now with podcast speedup

2009-06-17T04:20:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

The new iPhone 3.0 software was released a little under an hour ago. The upgrade was trivial. I clicked the Check For Update a few minutes after the release, and it downloaded the new OS in around 3 minutes! I recently switched ISPs so I have really good bandwidth now - but I had expected a lot of traffic on Apple's servers to slow things down.

The update looks really good. I tested a few of the things I have been looking forward to -- I personally don't care about the feature highlights listed on most sites, such as MMS, Copy and Paste, etc.

The first feature I've been waiting for is the ability in the browser to open a link in another window. With tabbed browsing I'm used to just ctrl-clicking on links such that pages load in the background, and when I'm done with the current page I go read the other tabs which by then are fully loaded. On the iPhone on the other hand I haven't been able to do this, since there hasn't been a way to open a link without throwing away the page you're on. But in 3.0, it's there - just click and hold a link and you get the option to open the link in a new page. It's not as good as tabbed browsing - it instantly jumps to the new, not yet loaded page, but it's trivial to jump back and keep reading while the new page is loading.

The second feature I've been waiting for is improved iPod controls. The primary usage for my iPhone is as an iPod - while running, doing chores or driving - and I listen to a lot of podcasts. With 3.0, the scrubbing feature is improved - it's now a lot easier to jump to arbitrary points in the podcast. I like to listen to This Week in Technology for example, but I'm getting really, REALLY sick of the 5+ minutes of Audible commercials in each and every episode. This is the DVR generation -- if a commercial is longer than 30 seconds I'm going to start resenting you. In 2.0 it was difficult to either fast forward (too slow, then too fast) or jump to arbitrary points in the podcast. With 3.0 it works really well - I just place my thumb on the scrollbar and lean it to the right then left to tweak the final endpoint.

Another iPod improvement is the ability to play podcasts at a faster rate. For the Java Posse some volunteers (thank you!) set up a server which would download our podcasts, apply audio processing to speed up the podcast, and then release these as faster versions of our episodes - called the Tempo Posse. This is no longer necessary with 3.0 - there's a button you can click to cycle between half speed, full speed and double speed playback:

I don't think this will run the Tempo Posse out of "business", because I looked at our download stats the other day and nearly half of all episodes are downloaded outside of iTunes! Are there really that many Zune users? ;-)

Code Advice #16: Don't Encode Symbol Type in Variable Names!

2009-06-16T07:10:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

(See intro for a background and caveats on these coding advice blog entries.)

I came across a JavaWorld coding-advice article the other day. While the thread which led me there referenced the second point of the article, I couldn't get past the first one where the author argues that

...a reader needs to know which items are local variables, which are fields, and which are method arguments. [...] It's likely best to use a simple naming convention to distinguish between these three cases.

I couldn't disagree more!

His key argument seems to be that when you are reading code, it's important to know whether something is a field since when you read a method, you might suddenly see a reference to something you haven't seen before. To make his point he shows this graphic:

His improved version is here:

I have a couple of problems with this.

First of all, why encode this information in the symbol name when IDEs will show this information automatically? NetBeans will show fields in greens, and statics in italics - and it will always be right, whereas the code might lie. Just like comments can get out of sync with reality, you could inline a field without remembering to change its name (especially if another developer did it without realizing the meaning of the variable prefix). Or if you get in the habit of seeing an "f" prefix as meaning field, what about local variables that legitimately should start with an f, such as "focus" ? Sure, the second variable should be capitalized, but what about typographically similar symbols like lowercase l and uppercase I?

Here's how the same function looks in NetBeans:

In addition to showing us the fields in clear green, the IDE also pointed out that this method is overriding another method (I hovered over the overrides glyph in the editor margin). The yellow line is warning us that this override doesn't have an @Override explicit annotation on it.
Information about overrides is just as important as whether an identifier is a field.

Highlighting fields in green isn't specific to Java... We do this for many other languages - see some screenshots of
Ruby, PHP, Groovy, etc.

Here's a snippet of JavaScript - notice how we have a reference to a global variable in there shown in green:

The key point here is that you shouldn't write your code to target reading code in black and white on paper. You shouldn't print out your code at all! Reading code with an IDE lets you easily check any condition you encounter (and just like in a browser there is a little go-back icon in the editor toolbar which maintains a visit stack so you can easily pursue multiple ctrl-clicks to track something down and then easily go back).

There are some other conventions left over from the days of code written on tiny terminals and printed out on paper for review - such as the "maximum 72 characters per line" limit. There's no reason for that when using modern tools. If the code is more readable unwrapped at 100 characters, leave it that way rather than introduce arbitrary breaks in the middle. (Having said that, don't take this as an endorsement to write deeply nested methods, that's a sign of poorly thought out design.)

My second objection to the article is that it is not clear to me that knowing whether something is a field or not is the critical piece of information you need. I think the following questions are probably more important:

What is the meaning of the variable, and what is the intended use?
Can it be null? Can it be negative?
What is its type?
Where else is it referenced?

And so on. Just prepending an "f" on a field reduces readability in order to avoid a simple lookup, when I believe you in general
need to know more context anyway.
And again, a tool can help you here. In NetBeans, hold down the Ctrl key (Command on the Mac) and hover over a symbol and you get help like
this:

(As a side note: I heard that at a Scala talk in JavaOne, Bill Venners was showing NetBeans through most of his talk, but he switched
to Eclipse to show one feature: Pointing at symbols show the actual inferred types of scala identifiers. Scala is as you know a statically
typed language, but uses a lot of type inference so the types aren't obvious from looking at the source. That's a very useful feature,
and I thought I'd point out that NetBeans has this feature too -- using the exact same mechanism as the above; just hold the Cmd/Ctrl key
and hover over a symbol, and you will see its type.)

Finally, the article makes a point that you probably want to distinguish parameters as well. I agree with that, but again not by changing
the name of the parameters, but through color identification. In Ruby, JavaScript, Python etc. we do that automatically in NetBeans - parameters are orange by default. For Java, it's not enabled by default (at one point it was, but somebody determined that the source code just looked too colorful, so the default color scheme was dialed back. I was working on Ruby at the time so my colors flew under the radar... and
all GSF-based languages such as JavaScript, Python, Scala etc. now inherit that color scheme...)

You can turn this on for Java as well. Just open the preferences, and for Fonts and Colors choose the Java language, then customize the Parameter Use and Parameter Declaration values:

Some languages like Ruby use sigils, where fields start with @, globals with $, symbols with : and so on. I don't have a problem with that
since I don't think these are as obtrusive as -letters- in variable names.

If you are reading code on paper, or with an editor that doesn't support semantic highlighting, you are voluntarily handicapping yourself.

Format All

2009-06-16T05:37:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

One feature I'm missing from NetBeans is the ability to format a whole project, or a package or directory. Opening each file only to press Ctrl-Shift-F to format it is just too cumbersome.

Fortunately, this is trivial to fix. I wrote a simple plugin to do this, and uploaded it to the Plugin Portal:

http://plugins.netbeans.org/PluginPortal/faces/PluginDetailPage.jsp?pluginid=18365.

Once you've installed the plugin, you can right click on projects, or select a project, package (nonrecursive folder) or directory, and choose Source | Format Files.

TODO: picture

TODO: team comment

TODO: Generic, not java specific.

The Authoring Tool

2009-06-08T04:23:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

We lifted the veil on the new designer tool for JavaFX last week at the JavaOne 2009 conference. Here's a screenshot:

The tool made a number of appearances:

First in the Tuesday keynote where my boss Nandini showed the basics of the tool.
Video,
starts at 23:08.
Then in the mobile keynote where Eric Klein showed the multiscreen support and mobile deployment.
Video,
starts at the beginning.
And finally in the Friday keynote where I got to do a longer 10 minute segment on the tool.
Video,
starts at 10:25.

The above video links just point to small chapters of each keynote; for full video replay go to
the keynote replay page.

I've scanned the blogosphere and twitter for comments on the tool and demos and the feedback is very positive.
Here's
a particularly detailed blog post with pictures and video snippets detailing the Friday demo.
Now we just need to finish the feature set, fix the bugs and polish everything! It's been a sprint for the whole team to get to this point. But we're not building a demo! We're building a product! So we're not getting much of a rest, it's right back to work to finish this thing!

(Photo by Balz Schreier)

P.S. In case you missed it, Larry Ellison from Oracle went on stage and made several comments regarding JavaFX in case the acquisition should happen - here's one article, there are many others.

P.S.2. We had our fourth annual Java Posse BOF live recording session last week. It was a blast. Dick stayed up editing and releasing
the podcast
the same night. If you're wondering what happened in the middle of the episode, where there's not much audio and a lot of laughing, that's me nearly drowning. I took a big swig of beer just as Joe made a joke; the beer went down the wrong tube, and then I was laughing so hard I couldn't breathe. My eyes were runny and I had beer all over my face and chest. Pretty embarrassing but reportedly also entertaining for others! Here's a photo from our get-together at a bar afterwards:

(Photo by Toni Epple)

Run Tests - Without Focus Loss!

2009-05-14T15:49:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

I like unit tests - but running them can be painful. Commit-validation tests
which bring up UI are obviously annoying, but even simple unit tests that
get in the way. Does this look familiar?

The above menubar should look familiar to anyone on a Mac who's run unit tests for client side
Java code. Not necessarily GUI tests, just any test where GUI libraries are loaded.

For every testcase, the test runner fires up a new process, which tells
OSX that "I'm graphical, give me focus!", and this steals the focus from the user.
The test finishes quickly thereafter, the process quits - and then the test runner
goes to the next test and the whole cycle starts over.

This is really painful because I like to have lots of tests. The Python editor support
for Netbeans had 600+ tests;
the counts for the JavaScript support was higher, and
the Ruby support even higher than that. Whenever I run tests, I basically have to
fight with my computer to get focus. Forget trying to write anything - every second
or so my keystrokes get stolen as the next test grabs focus - so I've gotten in
the habit of using the time for browsing, since I'm mostly reading, and I can handle
clicking a link a second time if the first click got lost. But every now and then
somebody will ping me on instant messaging - and it's maddening trying to respond while
this is going on.

If this is sounding painfully familiar to you, I have good news. I've finally figured
out a setup where this is no longer a problem!

The key discovery was that I can run my tests from another account on the system.
With OSX' fast user switching, I can switch to the alternate account, launch the
unit tests, and return back to my regular account where the tests won't interfere
with display focus. In order to let me run my tests from that other account, I
just open a terminal there and su -l tor in the shell to run all the
commands (or NetBeans) as myself.

This was a huge improvement since it removes the 10-30 minutes testrun downtime.
But it had some disadvantages - first, I don't like running tests from a shell, and second,
it's hard to know when things finish - and switching back and forth to check is annoying
since I always have passwords on my accounts so the machine isn't open.

So the second step was to set up Hudson (a
continuous integration server that is trivial to setup, and has a huge number of
plugins which makes
graphing code coverage, unit tests, findbugs results, integrating with version control
systems etc trivial. And it's
not just for Java developers.)

Instead of logging into the other account
for each test run, I log into the other account once, and start up Glassfish
with Hudson running. From now on I can access, configure and launch builds right
from my own browser in my primary account. The key step here is that Glassfish was
started from the secondary account, so its primary display is associated with the builder account.
When my build in Glassfish gets to the test stage, it's actually doing the display
connection just as before, and if I log into the secondary account, I get the annoying
focus flashing just as before. Look - the tested process is a user visible application in the dock:

Another improvement which really helped is the "File System" version control plugin for Hudson.
I want my Hudson builds to build my current working copy. I don't want to
check my code into Mercurial (even a local repository) just so that Hudson can
grab the code and build it. I want Hudson to build my current changes - my current
edits. After all, I'm trying to test them before checking in! And I discovered that
there is a plugin which will let me do that - it's just
a "file system" version control wrapper - which means you just point Hudson to your local
directory, and off it goes. When the build starts, it makes a quick disk-copy of the
source tree. Even though Mercurial cloning is pretty fast, this is even faster.
The disk copy also lets me specify a filter of files to exclude, so I had it ignore
*.class files. The diskcopy only takes 10 seconds or so before the build kicks
off, and it's building a snapshot of my current in-progress, edited working copy!
(It can also just update the copy based on changed filestamps - that's even faster,
but it didn't seem to correctly delete removed files, so I let it start from scratch
each time.)

(Note - this plugin isn't in the catalog that you can browse right from within the
Manage Plugins page within Hudson; I downloaded the .hpi file from
http://wiki.hudson-ci.org/display/HUDSON/File+System+SCM
and installed it in the Advanced tab.)

The final ingredient is the new Hudson support in NetBeans 6.7. I don't even have
to go to the browser to kick off build jobs. I just point NetBeans to my Hudson
server once, and from then on I have full Hudson integration. When I want to
run my tests I just select Launch job:

I get notified if there's a problem:

I can look at failures and logs:

I can see build logs etc. directly in the output window, and hyperlinks warp to directly to files - to the files as they were in the build, not the current state:

So to recap - with this setup, as I'm editing my code and I want to check the tests,
I just right click on a node and say "Start Job" - and off it goes without bothering
me at all - no more focus interruptions, and no more GUI windows popping up from
interactive tests. It's trivial to check the results. And it's even added one more
level of convenience: I have multiple projects, each with unit tests, and from the
IDE I couldn't have them all run with a single gesture. My build job does that.

I'm really stoked! I was at one point able to do this when I was working on Linux
and Solaris by setting my $DISPLAY variable and doing tricks with VNC. But that
still required my tests to run in a console - which made interpreting the results sucky.

If you haven't played with Hudson, try it - it's unbelievably easy to set up. Just download
the Glassfish appserver and install it, download the Hudson .war file, and drop the hudson.war
into the autodeploy directory of the appserver, and browse to localhost:8080/hudson.
Once you're there you can install
plugins (under Manage hudson), point to your local installations of the JDK, ant,
etc., and configure your build jobs by running scripts, launching maven scripts, writing
ruby scripts, or obviously running ant scripts.

Some final miscellaneous tips:

I don't want Time Machine to back up my builds trees, or Spotlight to
index data in these directories, so I went to the TimeMachine preferences and had it
exclude the ~/.hudson/jobs/ directory.

I did the same thing for Spotlight - but unlike
the Time Machine preferences, there was no checkbox to "Display Invisible Files" (e.g.
files that start with a dot, such as .hudson) in its file chooser. Here's a tip I didn't
learn until recently: When a Mac filechooser has focus, you can press slash (/) - and this
will open a text field where you can directly type the path it should jump to. I typed
/Users/tor/.hudson and from there I was able to select the jobs directory to exclude.

You might be tempted to skip the "filesystem version control" plugin and just have
your build symlink to your working copy. Be careful; if Hudson is configured to delete
older builds you might find yourself without your source code. I'm not saying it will
follow your symlinks - Java has support for symlinks now - but I haven't tried it, and
I have been bitten by ant in the past where it decided to follow symlinks in its
zeal to delete recursively!

I recently discovered that you can reorder the build steps in a Hudson job. The little
graphic to the left of a build task is a handle you can just drag to reorder!

...at least my house didn't burn down!

2009-05-12T10:07:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

As I was working yesterday my laptop felt kinda wobbly. I didn't think too much about it. But it started getting annoying. I lifted the laptop and looked under it to make sure my laptop wasn't accidentally sitting on top of a USB cable or something like that. Nope.

A little while later I was getting really annoyed - so I flipped the computer all the over to see what was up. And to my surprise my battery was completely warped. It looks like it had "exploded" sometime this weekend. Check out how warped it is:

A couple of years ago one of my Apple power supplies would make humming noices now and then, and one day I happened to be looking at it when it shot some sparks! Luckily I had a floor mat so any previous sparks hadn't ignited the carpet. I got that adapter replaced. But I'm definitely thankful neither incident caused fires!

JavaFX editing tips!

2009-04-29T10:42:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

The NetBeans support for editing JavaFX isn't as mature as for other languages. After working with it for a little bit I've figured out a few things you might find helpful:

One thing I do a lot when experimenting with FX is trying to comment out parts of the scenegraph to try different things.
The way I comment/uncomment
in NetBeans is using the Toggle Comment action -- Ctrl-/ or Cmd-/ depending on your platform. But in JavaFX that keystroke does nothing!
It turns out they have implemented Comment and Uncomment, just not toggle. So you can just use those actions instead (they're in
the editor toolbar on the right.)

Or, if you're like me, you really want Toggle Comment. Especially because it has a keybinding. In that case you can install
this plugin which adds toggle comment
support for .fx files. It's a trivial module (just two small files (1,2)) so I'm hoping this will be
included in the next version.

The second issue I ran into is that the editor sometimes tells me my source code is wrong - and I'll stare at it without figuring out
the problem. Turns out - I'm often right. The code is okay, and the background parser is confused. At the
roundup a number of other people ran into this bug.

Fortunately, there's a simple workaround for this - just select all (Ctrl-A), hit delete to wipe the file clean,
and then undo (Ctrl-Z). You'll get your source
file back, and the file should be (re)parsed correctly. It looks like there is some kind of incremental parsing bug. If you disagree
with what the IDE error message is telling you, go ahead and try this workaround.

Here's an example. The editor is telling me I have an invalid assignment -- huh? There's no assignment there!

If I select all, delete, paste, I get this - all better:

An annoying bug, but once you know about it it's pretty trivial to work around it.

At first I thought code completion was really broken. Let's say I wanted to insert a DropShadow. Not knowing
where it lives I would just type DropS to get NetBeans to show it to me and also import it for me (and advantage
of using code completion instead of just typing the name). But that just didn't work - after typing DropShadow and
attempting code completion it wouldn't show me any matches!

Turns out there's another workaround for this. Just hit Ctrl-Space again! In the Java editor, we distinguish between
completing only the imported classes and all available classes. If you for example have imported a class named "Video"
in your class and you code complete on "V", it will not list "Vector" as a match (unless that class is also already imported) -
it will only show the imported classes that match the V prefix. If you press Ctrl-Space a second time, you get to see all
V matches. Of course, the code completion dialog tells you this - it says "Imported Items; Press Ctrl-Space Again for All Items" right
there in the list.

However, this never seems to bite me when coding Java, because it does something else: If there is no match, it will proceed to do
the all-items completion on its own - so most people don't have to think about it. The JavaFX editor on the other hand does not do this
so you end up typing a prefix you know exist, complete, and - nothing.

The workaround is simple - just press Ctrl-Space a second time when this happens, and voila - the class shows up and gets imported
as well. Of course - the message at the bottom of the semi-empty code completion window says as much, but since you don't usually
have to pay attention to this in Java (because it auto imports when there isn't a prefix match) you might have missed it:

Import Management. At first I would try to just type "DropShadow { }" - and the editor would complain that it doesn't
know what I'm talking about. Alt-Shift-i, which imports the symbol under the caret doesn't do anything.
But it turns out that Cmd-Shift-i, Fix All Imports, DOES work. So use that one instead. It doesn't give you the dialog
you get in Java showing all the matches; instead it works its way sequentially through all missing symbols.

P.S. Fix Imports also cleans up unused imports.

The Preview Panel seems to be a bit hit or miss. I loved using it, but I would occasionally get lots of exceptions from it,
so now I only use it for simple scenegraph experiments and tend to just run instead to test stuff - it's been fast enough.

The main thing I'm missing is keyboard navigation among occurrences. As you (hopefully) know, Ctrl-Up and Ctrl-Down lets you
cycle through the yellow occurrences of a symbol when you're editing Java, JavaScript, Ruby, etc. This is really handy since
it gives you instant "find usages" within a file - just click on a symbol and ctrl-down to cycle through the references.
JavaFX has mark occurrences - but unfortunately they're missing the small code to iterate this through the keyboard.
I thought I could just add that trivially along with the toggle-comment code plugin above, but unlike toggle comment which
took 3 minutes to write, I couldn't see a simple (30 minutes or less) way to get access to the occurrences highlights from
the outside, so I instead fired
off an e-mail to the FX editor team - I'm crossing my fingers that they can get this in the next version!

Nice touch, Skype!

2009-04-27T06:34:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

I work from home, so I rely heavily on Instant Messaging and IRC to communicate with my co-workers, and for video conferencing I use Skype.

I sometimes make typing mistakes. And if the typo is particularly embarrassing, to the extent that I want to fix it to show that I know better,
I usually write something like this:


12:00   I agre.
12:00   s/agre/agree/

Anybody with vi experience or even sed experience will recognize the second line as a search/replace command, so I'm really saying "I said agre but I meant agree". It's reflex at this point - I'll do it for the most minor accident.

I usually only use Skype for video conferencing, not instant messaging. But I just discovered, by accident, that Skype does something wonderful. Instead of showing my substitution command, it applies it to the previous line, instantly, on both sides of the conversation! Look at this:

Ugh, typo, reflexively type s/foo/bar

Voila:

Instead of adding my correction command to the log for the viewer to interpret, it just edited the previous command in place. If I can type this quickly enough, perhaps the reader won't notice!

Chatzilla, Adium, Others - Please please please do this too!

P.S. On the topic of terminal conventions.... I like using ^H's as a "just kidding" device:


12:00   Ok, I'll slap^H^H^H^H tell him about it.

Anyone who's logged into terminals with wrong tty settings will recognize the ^H's as failed backspaces... And I don't want IM clients processing these :)

Catchup

2009-04-24T06:42:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

A lot of stuff is happening these days, so here are some quickies... is this what people use Twitter for?

My brother is visiting me these days. He's in town for the MySQL conference, where he presented his work on memcached. He's also a huge fan of Solaris, so I'm now running OpenSolaris on my desktop machine. It's fun to see how user friendly the (always powerful) operating system has gotten. And his blog entries like this and this take me back to my first job at Sun - working on the Solaris debugger UI. Good memories.

Yesterday was "Take Your Daughters and Sons to Work Day", so I brought my kids down to the Santa Clara campus. They had a great time. After "working" in an office while I was on my laptop, we walked around the campus, they met my boss, and I'm sure the highlight for them was having lunch in the Sun cafeteria - which even had a special kids menu for the day. In our walk through some of the buildings we came across a pool table where they got to try pool for the first time.

I had the honor of being interviewed on the PlanetCast a week or two ago. That's the third episode of the podcast, but do yourself a favor and listen to the first two - with John Rose on the DaVinci Machine Project, and James Gosling on Java and JavaFX. I've had to drive down to the Valley almost every day the last couple of weeks for meetings, so the timing of my discovery of the PlanetCast couldn't have been better!

My friend Carl Quinn just got his Tesla - an all electric super sporty car. He's waited two years or so since he ordered it and they're just now coming off the assembly line. When we got together for a podcast recording session Wednesday night he brought the car, and took each of us for a spin around the block. Wow! It felt like like getting a ride in a fighter jet - but while the acceleration force was amazing, unlike a jet the all electric motor is unbelievably silent. I can't wait for cars like these to get to mass market! There are some pictures of our rides on Jackie's blog, and Joe has a lot more pictures and even some video.

The Ruby support in NetBeans 6.7 is coming along nicely. Erno just announced that preliminary Ruby 1.9 support is in the builds now. More details on that in his blog entry. And in another blog entry he's describing work he and Martin did recently to improve the type inference support in NetBeans. Here's some Ruby 1.9 goodness:

Finally, we're using JIRA as the issue tracker for the JavaFX project, so I've been using Cubeon for NetBeans a lot recently to handle querying and updating issues from within the IDE. I don't have Eclipse envy, but I'm impressed by their Mylyn project which looks both nice and useful, so I definitely welcome task oriented flow into NetBeans as well. In addition to connecting to repositories like Bugzilla, JIRA and Trac, Cubeon adds some basic support for tasks (e.g. when you "activate" one task, all breakpoints you set in the debugger get grouped and associated with this task and so on), so I'll be playing more with that. I'm using a daily snapshot rather than the most recent published version, and I'm pretty happy with it. I'll probably have more to say about this in another blog entry as I get more experience with it.

Add Effects to the right Container!

2009-04-07T12:38:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

The Flubber application I described earlier has an old stop-watch style timer with second and minute hands:

Making the clock hand move was trivial using value binding and a rotation transform on the hand graphics object:


transforms: Rotate {
angle: bind (360.0 / 60 * minutes) - 90.0
}

Since we are using a binding expression, setting the minutes variable anywhere (and yes, assigning to it!) will cause the hand angle to be recomputed and the graphics updated.

Anyway - once we had the clock moving, the first thing we wanted to do was improve the look of the clock by adding a drop
shadow. That was trivial; all we had to add was this:


effect: DropShadow {
offsetX: 5
offsetY: 5
color: Color.BLACK
radius: 10
}

That looked pretty good:

But look what happened when we let the timer run... Where is the light source?

What's happening here is that the drop shadow is rotating with the hand. Not what we want.
We were all learning JavaFX that day, so we hacked it, using the following code:


effect: DropShadow {
offsetX: bind Math.sin(Math.toRadians(handAngle + 45)) * 5.0
offsetY: bind Math.cos(Math.toRadians(handAngle + 45)) * 5.0
color: Color.BLACK
radius: 10
}

Now, the drop shadow offset moves along with the rotation such that the shadow always appears in the right place.
It worked, and we moved on.

Now that I understand JavaFX and the scenegraph a bit better I realize that this approach is wrong - there's a much simpler solution!
We don't want to apply the drop shadow to the Path object directly, since the path is what we are rotating with our minute angle.
Instead, we should simply move the effect out to the surrounding parent. That will apply the drop shadow after the shape
has been rotated.
Doing that, we can set our drop shadow initialization back to the original simple 5,5 delta, and we get exactly the result we want:

So, think about which node you apply effects to! And by the way, the effects framework is really fun to play with - you should definitely
explore javafx.scene.effect.* !

JavaFX Text Component

2009-03-23T02:51:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

At the Roundup a few weeks ago we rewrote the old Swing JFlubber application to JavaFX. We had a brand new graphical design done in PhotoShop, and we hooked up the functionality with some swanky effects. I might get into that in another blog entry.

But one challenge we ran into was that of displaying text. In the Flubber application we need to have an editable text area where flub times are automatically inserted and the user can add additional comments. JavaFX makes it easy to throw some simple text in a design, but edit, scroll, and so on? Not yet.

Proper GUI components for JavaFX is coming. But in the mean time, there are some tricks you can use. Put simply, you can use a Swing text area, but without looking like Swing. Here's how. First, create a JavaFX scenegraph node for the Swing text component:


var textPane = new JTextPane();
var scrollPane = new JScrollPane(textPane);
var text: SwingComponent = SwingComponent.wrap(scrollPane);

Let's see how that looks:

Ugh!! Not what we want. Obviously, we don't want the text area to look like Swing... we have a nice background as part of the PhotoShop design that we want to use under below the text. But that's not hard to fix. Java colors have an alpha channel, for opacity. We can use a completely transparent background on the text area to make it just pass through its background (and we have to make the scroll pane nonopaque as well):


textPane.setBackground(new java.awt.Color(0,0,0,0)); // 0 opacity => 100% transparent!
textPane.setForeground(java.awt.Color.WHITE);
textPane.setCaretColor(java.awt.Color.WHITE);
scrollPane.setOpaque(false);

Let's try again:

Much better! But there is still a gray rectangle on top of the graphics, placed there by the border of the scrollpane. We can get rid of that too:


scrollPane.setBorder(new EmptyBorder(new Insets(0,0,0,0)));

Now we're talking! But the font is too small. Dick told me he wants to use a Courier font. So let's try this one:


textPane.setFont(new java.awt.Font("American Typewriter", 0, 14));

Here's what we get:

Ewwwwww! The font is not antialiased. I tried a bunch of things to fix this -- for example setting antialias rendering hints on the component itself, setting the aa system property, etc. It looks like there is a bug here in that the rendering hints aren't picked up properly for the wrapped Swing components. But I did find a workaround that works: We can set the antialiasing rendering hints directly on the graphics object ourselves. That means we need to get involved in the painting of the component itself, but luckily that's trivial. Instead of creating a new JTextPane, we'll create a simple subclass of it where we override the paint method to add the rendering hints:


import java.awt.Graphics;
import java.awt.Graphics2D;
import java.awt.RenderingHints;
import javax.swing.JTextPane;

public class AntiAliasedTextArea extends JTextPane
{
@Override
public void paint(Graphics g)
{
Graphics2D g2d = (Graphics2D) g;
g2d.setRenderingHint(RenderingHints.KEY_TEXT_ANTIALIASING,
RenderingHints.VALUE_TEXT_ANTIALIAS_ON);
super.paint(g);
}
}

Now we can just change


var textPane = new JTextPane();


var textPane = new AntiAliasedTextPane();

and we get this:

Ta-da!

But there is one more problem... What if we add a lot of text:

Scrollbars! We don't want those. This text pane won't be used for much text, so you can just move the caret around like in a text field to navigate the overflow content. So let's turn off the scrollbars:


scrollPane.setVerticalScrollBarPolicy(JScrollPane.VERTICAL_SCROLLBAR_NEVER);
scrollPane.setHorizontalScrollBarPolicy(JScrollPane.HORIZONTAL_SCROLLBAR_NEVER);

and with that, the text pane behaves exactly the way we want. Now you can manipulate text in the usual way: textPane.setText(string), textPane.getText(), etc.

While we're at it, let's fix the selection colors as well such that when you select text you don't get the telltale Swing light blue:


textPane.setSelectionColor(new Color(255, 255, 255, 50));
textPane.setSelectedTextColor(new Color(255, 255, 255, 255));

Note again how we can use transparency on this colors to give a nice glass effect on the selection (I also bumped up the font size):

Hopefully these tricks will help you with your text needs until we have real JavaFX components...

NetBeans Screenshot of the Week 42: JavaScript Native Interface

2009-03-16T03:37:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

At the Roundup last week I talked to
Robert Cooper, who's doing a lot of interesting work with GWT (Google Web Toolkit). In GWT (which compiles Java to JavaScript), you can embed JavaScript directly within the Java files inside comments with special markers. Robert mentioned that IntelliJ has a nice feature for GWT programmers where your native JavaScript snippets get JavaScript highlighting etc.

I figured that would be a trivial thing to add to NetBeans with our language embedding infrastructure. Sure enough, the patch just adds 13 lines of code. Here's a screenshot - showing JavaScript (regular expressions etc) inside Java code (with packages etc) - it's inside comments that start and end with -{ and }-:

If you want this functionality in your own 7.0 build, just download this module nbm, or apply the patch to your own build.

Java Posse Roundup 2009

2009-03-12T10:53:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

I just got back from the Java Posse Roundup 2009. It was our third year (blog entries from 2007, 2008), and therefore I can add "as usual" when I state that it was a wonderful time.

This year's topic was "developer productivity", which is obviously a passion of mine, so I found all the technical sessions thoroughly enjoyable. We recorded all of them so they will be released slowly through the regular podcast channel.

I was able to redeem myself from last year's skiing disaster but not falling doesn't make very compelling video...

Another highlight is the lightning talks. This year we had two hours of lightning talks every night. We'll be releasing those on a quicker schedule as YouTube videos in our YouTube channel. I can recommend Barry Hawkins' talk as a starter. The nice thing about lightning talks are that they are short so go ahead, give it a try!

In order to enforce the 5 minute rule for lightning talks, we wrote a little timer app, as seen in this picture:

The laptop on the left is running our downcounter. It starts at 5 minutes, and when it gets down to 0 it plays a sound effect which politely asks the user to, ehm, stop. We wrote this app as a collaboration on the first day of the conference, during the language dojos. We had 3-4 sites where different people studied Scala, Groovy, Python, Fan and JavaFX, according to their interests. In the JavaFX group we played around with the language in the morning, and then decided to build something real - the countdown timer. We needed a sound effect to play when the timer expires, so we held up one of our conference audio recorders and all at once yelled "Shut Up!" into it. In the room next door Dick Wall had just started talking about Scala, and our brief recording session apparently caused some confusion...

P.S. There are a lot of pictures from the Roundup on flickr.
The below are by Joe Nuxoll.

Crested Butte, Colorado by night:

The first day of the Open Conference we held a languages-on-the-JVM dojo. This is a picture of those of us playing with JavaFX:

The lightning talks schedule for the Tuesday night:

On Thursday we had a progressive dinner where each household served one course for the other participants. Carl made Indian Style chicken wings and Ido is getting ready to serve:

Dick and Dianne talking during the progressive dinner.

New Job

2009-03-11T11:47:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

Apologies for the recent blog silence for me. It's not that I've been slacking off. Quite to the contrary!
The biggest news is that I've changed teams: I'm now working on JavaFX! And more specifically, the designer tool.

If you don't know what JavaFX is, you're probably reading my blog because you're interested in Ruby, Python or the various other languages for NetBeans I've been involved with. If so, fear not - NetBeans language support is in great hands - Erno just improved the Rails dynamic finders code completion for Ruby for example. Of course, as an open source project we can always use more contributors! I've received a bunch of patches for the Python support recently which I've been happy to apply immediately. Keep 'em coming!

Briefly, JavaFX is a new UI stack for Java which makes it trivial to build pretty, dynamic and interactive UIs. While Java has always made it easy to target multiple operating systems, JavaFX makes it easy to target the completely separate platforms of desktop, web and mobile. If you haven't looked into it, you should.

JavaFX has its own language, JavaFX Script. It has some language level features which makes it really suited to building UI applications - from something simple like a literal for durations (so you can write 2m or 5s or 250ms in your source code), to something advanced like variable bindings which give you all of the power of traditional property change listeners, but without the pain (and it's more powerful than that - you can for example bind the rotation angle of a clock hand to an expression which computes the angle from the current time, and whenever the time variable changes the clock hand rotation is updated.) As a Java developer (and a Ruby and Python and JavaScript coder as well) I can truly say I've seen some things in JavaFX Script that I would like to see in other languages. I might talk about that in an upcoming blog entry.

If you're one of the alternate-languages-on-the-JVM people, I think you should seriously look into adding a binding layer for the JavaFX platform to your language. Libraries like Groovy Swingbuilders (and similar libraries for Ruby etc) have made Swing more accessible, but at the end of the day you're still dealing with Swing. If you want to add drop shadows, transition animations etc. a JavaFX DSL would be a much better approach. And besides, we're firing on all 256 cylinders on the JavaFX platform -- from the base Java platform (adding modularity so we can provide a barebones FX runtime), to the graphics system, to components, to the language, and up to the designer tool! I think it's going to shake up the RIA space - which is why I wanted to be part of it.

I promise my next blog entry won't be long in waiting, I've got a bunch of things queued up!

NetBeans Screenshot of the Week #41: Type Assertions

2009-01-13T02:52:00.000-08:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

Python and Ruby are dynamically typed languages. We have a lot of heuristics in our editors to figure out the types - tracking assignments, analyzing your database migrations, etc - to help code completion, go to declaration and other IDE features work correctly. And Martin Krauskopf, who owns the Ruby editor now, has been improving the type inference for Ruby a lot lately.

However, there are cases where we just can't help. What if you're writing a brand new method you haven't called from anywhere, and you're trying to access methods on one of your parameters? We don't know the type of the parameter. In that case, NetBeans will provide "fallback code completion" - it will list ALL methods across ALL known classes in your project, libraries and current platform.

If you're looking for the documentation or parameters for a specific method - that's useful - after typing 2-3 characters you've typically narrowed the result set down to a handful of methods and you can pick the one you're looking for.

But what if you're not sure what the method is called? That exact scenario happened to me a couple of days ago. I was writing some Python code to do some string manipulation, and not being very familiar with Python I wanted to know what the equivalent of Java's indexOf method was in Python. I knew that the parameter in my method was a String, but I didn't have a way of telling the IDE that. I applied my usual workaround of adding a line above the current call:


x = ""

and then I could invoke x. to see the methods available for a String. However, that's definitely not a good way to do it. What if I forget to remove my fake assignment? (Yep, I did that too. I couldn't figure out why my code wasn't working until I debugged and realized I was clearing out the parameter with a bogus assignment... Doh!)

The "obvious" solution for this is supporting type assertions. We've had those for a long time in the Ruby editor
(picture), and obviously for JavaScript using the @type and @param {type} syntax. And the PHP editor just added support for type assertions as well (more here and here).

I've just added this for the Python editor as well. But I've gone one step further which I think makes the feature much more obvious, and easy to use. In code completion, if the editor detects that you are attempting to complete on a simple variable (as opposed to for example a complicated expression), and the type of that variable cannot be resolved, then we add a new special code completion item at the top of the list. Here's what it says (and a more detailed explanation in the documentation popup):

As soon as you press enter, the IDE will insert a special comment referencing the variable you were completing on, and automatically invoke code completion again to complete on the type statement:

The contents of this list has two parts: First, it lists the pseudo-types for many of the core builtin types, like ints, strings, lists and tuples. After that it will list all the known types in the system, such as the user and library classes. If you select one of these and try code completing the original expression again, you can now see that the type resolver knows what to do:

A couple of notes about this. First, note that the type assertions are just comments in your source. You can delete them - they are merely an aid to the IDE. Not only code completion uses these - go to declaration for example will also be more accurate if it is explicitly told the type of a variable it cannot figure out. You can also use multiple type assertions within a method in case the variable type changes during the method. This isn't the case with Ruby yet; the type assertions apply to parameters only, at the method level. But Martin has promised to look into this for Ruby as well so hopefully there will be full parity between the two editors shortly!

P.S. Just like in the PHP editor, mark occurrences and instant rename are type-assertion-aware:

NetBeans Screenshot of the Week #40: Python Test Runner UI

2009-01-05T04:51:00.000-08:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

In the 7.0 builds, we have a dedicated unit test runner for Python now. Running a file as a test, or running the test project action, will open a test runner with the output docked on its right hand side, instead of just the output window (click for full size screenshot):

Here's the test runner itself:

What you want to see in the output is a single green line which says "All n Tests Passed", where n is hopefully a large number. But when one or more of the tests fail, you see something like the above. Running the Next Error action (Cmd-.) will jump to the next failed test, just like it normally jumps to the next error in the current output window, or the next task in the tasklist.

One thing to notice (and this is new in 7.0) is that we now include the failure message right there in the test summary for each test, so you don't have to drill into an individual test to see the failure message. You can also hover over a test and any output from that test is shown in a tooltip. You can also right click on tests and select "Run Again" to run just one specific test over again.

This is the same window as the one we have for Ruby. In fact, Erno, who wrote the Ruby test runner, has modularized the code now such that it's the same implementation for both languages - we just have language specific plugins to actually hook into the various testing frameworks. Currently, for Python we support the two builtin testing frameworks: unittest and doctest. The above screenshot showed a regular unittest run. Here's a doctest:

One important thing to note is that you don't have to instrument your code with any test running code. As long as you place doctests in your docstrings, or as long as you have any classes extending unittest.TestCase, the test runner will find them. All you have to do is run Test Project:

and when you have done that, both unittests and doctests are found and included in the same test run - here's both failing doctests and unit tests:

Once again, kudos to Erno for writing the excellent test runner support! And as usual, let us know of any problems.

P.S. Jean-Yves Mengant has also done some excellent work recently. In addition to some cool new quickfixes in the Python editor for NetBeans, he has just integrated a multithreaded debugger for Python!

Ruby Code Coverage in the builds now

2009-01-02T03:37:00.000-08:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

I've checked the Ruby code coverage code into the trunk now, so if you grab a recent daily 7.0 build, it should be there. I found a Windows-specific bug in the Python code coverage code as well, so grab a new build if you're on that platform.

I've had some fun with Java2D lately. Instead of the ugly coverage bars I showed in my screenshots a couple of weeks ago, the coverage bars now have proper gradients, drop shadows behind the text etc.:

Another thing I added is a bar in the editor footer (while code coverage is enabled) which lists the coverage percentage for the current file, along with actions to quickly run the tests again, or bring up the coverage report, or clear the results, or finish the coverage mode. As well as warn you when your data is older than your code.

And finally, I updated the built-in and extra color themes to also have color definitions for the coverage highlights. Here's the Dark Pastels color theme with coverage data enabled:

Please let me know of any problems while this code is still fresh in my mind :)

Happy New Year!

2008-12-31T06:16:00.000-08:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

My music teacher in middle school had a great tradition. Every New Years Eve, at midnight, he would lift his stereo speakers up to his open windows, and on full blast, play ABBA's "Happy New Year" for the neighborhood.

I'm going to do the same thing here, on my little corner of the internet. Enjoy!

My kids have recently discovered ABBA through the Mamma Mia movie. Now they want to listen
to ABBA when we're driving around. No, don't pity me - it's a lot better than what they usually
want to listen to (I'm looking at you, Hannah Montana!). And besides, having grown up
in Norway I'm an ABBA fan at heart. When I was in 4th grade, all the girls in my class
liked ABBA, all the boys in my class liked Kiss, and then there was me - I sided with
the girls. And I'm still not ashamed of it. Despite some of their ridiculous outfits,
ABBA created some timeless melodies and had great sound production values that hold
up to this day.

VirtualBox Rocks!

2008-12-23T07:17:00.000-08:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

In order to get code coverage to work seamlessly in the presence of the Rake build tool, I had to do some pretty ugly tricks - a lot of path manipulation that surely won't work on Windows. Rather than just getting bug reports, I'll need to debug through it to find the troublespots and fix them.

I don't have a Windows machine. I have a Solaris desktop box, and a Mac laptop. And since I don't have any short term plans to go in to the office (I work from home most of the time) I don't want to wait to look into this until my next chance to stop by a computer lab with Windows machines.

So, I decided to dust off the VirtualBox instance I installed and tested a while back. Back then, it worked fine - but was a bit painful to use. Actually, it was my fault. I never went and "finished" my installation. Turns out, after installing Windows on the virtual machine, there is some additional software shipped with VirtualBox that can be installed into Windows to make things work more smoothly.
For example, a special mouse driver makes the Mac mouse also work as the Windows mouse. There's support to share file systems. This is a huge benefit. I simply mapped my working source tree that I have already checked out, edited and built, as a new Windows drive! I didn't have to go and install Mercurial, Python, check out the whole NeBeans source tree, build it, etc. I could simply open up drive Z:, and run the NetBeans IDE from within Windows!

Another cool thing these special tools add is "seamless mode". I'm running the Windows applications running as if they are regular Mac applications on my Mac desktop! So I can debug through my Windows instance of NetBeans while at the same time having my Mac mail and instant messaging programs part of the screen. Look at the below screenshot (click for full size) -- I have the Mac doc on the left, and the Windows doc on the bottom - as well as a mixture of Mac and Windows (uhm) windows on the desktop!

There's my mailtool again... Last year I posted a screenshot showing how I had 13,000 unread mails, but plans to finally catch up. I guess I didn't put that high enough up on my priority list. The above screenshot shows how I'm up to 56,000 unread mails now. Ugh. Oh well, at least the number of unread mails addressed directly to me is decreasing.

Wow. Installation was flawless. It's working beautifully. And it's free. And it's open source. Wow. Oh, and it runs on many other platforms as well.

As I wrote this blog entry I looked up the VirtualBox home page to I could link to it, and I discovered a news blurb:

New Dec 17, 2008

VirtualBox 2.1.0 released!

Sun today released VirtualBox 2.1.0, a major update with exciting new features: among them better 64-bit support, hardware virtualization on the Mac, 3D acceleration, easier networking on Windows and Linux plus full VMDK/VHD support including snapshots. See the ChangeLog for a detailed list of changes.

I just installed it and took it for a quick spin, and things are looking great.

P.S. One little tip: Installing the Guest Additions into Windows is easy - there's a menu item in the Device menu, "Install Guest Additions...". I tried it, and it popped up an installer inside Windows. But since I was in the middle of applying service packs to Windows, I dismissed it so I could deal with it after my service pack upgrade reboot. But when I tried it later, it didn't work! Uh oh, is this incompatible with service pack 3 I wonder? Nope, it's much simpler than that. What "Install Guest Additions..." does, is mount a new CD-ROM into Windows. I'm guessing Service Pack 3 turns off auto-run! Probably a security thing. So all I had to do was open the computer folder, and click on the CD-ROM there to run the installer.

Oh, one other tip: The default RAM allocated to the virtual machine is pretty small: 512Mb. In the Settings for the machine you can crank it up bigger - I set it to 2 Gb. That makes the machine run quite a bit faster under load since it's not continually swapping to disk for virtual memory.

JavaOne Submissions Due

2008-12-18T09:29:00.000-08:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

The deadline for submitting talks for JavaOne 2009 is almost here. I was on one of the review committees last year, and saw many common patterns for rejected talks. I wrote these up in a blog entry last year - "Why Your JavaOne Submission Was Rejected. You might want to skim through it again while reviewing your submissions one final time!

Also, there's a new book about develping Ruby and Rails code with NetBeans, written by Chris Kutler and Brian Leonard. I reviewed some of the content and it looked very good. There are a lot of books on Ruby and Rails, but this book really shows you how to do things effectively with NetBeans. Mastering your tools is one of the best gifts you can give yourself as a developer (or as a craftsman of any craft, I think). I gave this advice a while back when I was interviewed for the JavaOne daily newspaper. Highlights from these interviews were recently compiled in this article, containing advice for students from a variety of developers. When this article was discussed on DZone I was surprised to see some people still talk about IDEs as something to be avoided until you know what you're doing. I think precisely when you are new to Java should you use an IDE to help you explore IDEs, to pinpoint errors are you're typing code rather when you try to run javac from the command line etc. The same goes for Ruby, Python, PHP, and so on. The IDEs let you explore APIs using code completion and go to declaration, they present important operations in project and execution menus, quickfixes and semantic warnings pinpoint errors in your code, and so on. If you're still writing code with Notepad, you're missing out.

NetBeans Screenshot of the Week #39: Ruby Code Coverage, Python Code Coverage

2008-12-16T10:09:00.000-08:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

Here's a new feature for NetBeans 7.0: Code Coverage support!

First a screenshot:

There are a couple of key points about the code coverage support:

It is fully integrated into the IDE, and especially the editor. You don't get read-only views of your files with coverage information; the files themselves include coverage highlights. You can view and edit the code directly, use your normal IDE navigation commands to jump around, and so on.
Enabling and disabling code coverage is trivial. There is no need to modify your build files, run special rake targets etc. Just select the menu checkbox to enable coverage in the new Code Coverage project menu, and then continue as before - run unit tests, run files, run the tests in your project - and the results are updated live as soon as the executed process finishes.

I didn't think a screenshot really described this feature well, so I recorded a couple of quick sessions where I use the feature:

Here's Ruby (Quicktime, 8.1 Mb, 2 minutes 11 seconds, click on the image - or low-res youtube version):
Here's Python (Quicktime, 4.3 Mb, 1 minute 5 seconds, click on the image - or low-res youtube version):

Here's a couple more images if you have problems loading the videos:

The Python version is already in the 7.0 builds. The Ruby support isn't integrated yet; it probably needs some tweaking to make it work on Windows.

NetBeans Screenshot of the Week #38: E4X Support

2008-11-28T02:14:00.000-08:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

As part of the JavaScript 1.7 work,
I also beefed up the E4X support. E4X allows you to embed XML objects
directly in your JavaScript source. Here's some simple E4X JavaScript:

We've had E4X support in NetBeans in both NetBeans 6.1 and 6.5. But now, in NetBeans 7.0, semantic highlighting is E4X aware, such that the source code looks like this instead:

The whole XML document declaration has a faint purple background, element names are blue and document content is bolded.
(The green here, as for all JavaScript code in NetBeans, indicates variables in global scope.)

Another new E4X feature is formatting/pretty printing. If you press Alt-Shift-F to format the above source, the E4X is
reformatted and indented:

In addition, the navigator window shows the logical structure of the XML document as well. Clicking in the source
will expand and select the corresponding item in the navigator, and conversely double clicking in the navigator
warps the source to the corresponding location in the XML declaration:

Finally, there's some primitive support in code completion for the XML document:

NetBeans Screenshot of the Week #37: JavaScript 1.7 Support

2008-11-25T06:46:00.000-08:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

I just checked in support for JavaScript 1.7. This means that NetBeans will no longer give you syntax errors if you try to use the new language. Here are some screenshots. First, let's open a file using JavaScript 1.7 constructs:

Obviously the file is using yield which is not recognized as a keyword, and in particular, this is just a syntax error - the parser was expecting a semicolon. But there's a little lightbulb... let's see what it says (type Alt-Enter or click on the lightbulb):

Let's select the option to change the active language to 1.7. I could also open the JavaScript options dialog directly and set it to 1.7 as shown here:

After applying the language change, the editor immediately re-lexes and reparses the file according to the new language. The errors are gone, and yield is now a proper keyword:

Similarly, the let keyword can be used, as well as destructuring assignments, generators and iterators, etc. (See New In JavaScript 1.7 for more information).

If you place the caret on function definitions, it will highlight all exit points, and this includes yields now.

This work isn't done; I'd like it to be smarter about generators, and there may be some issues with scope handling. But at least the editor doesn't get in your way with false error messages now - you can start writing JavaScript 1.7 clean code. (This is with NetBeans 7.0 dev).

In related news, I just heard from Tom Enebo that a lot of Ruby 1.9 language features are now supported by the JRuby trunk parser, so hopefully we can soon start fully supporting Ruby 1.9 features in NetBeans as well.

NetBeans Screenshot of the Week #36: Python Code Completion

2008-11-14T01:30:00.000-08:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

Here are some screenshots of the code completion working for Python.
First, let's try it from an import statement:

Note that the documentation for the module is shown. Next, let's
try completing on imported symbols - again we've got the documentation:

I'm writing a unit test, extending TestCase. Now let's try overriding
some methods - completion after typing def:

Obviously, invoking methods on self. will show the inherited
methods - and their documentation:

Here's completion in my function (not on self) showing
the local variables, imported symbols and builtins. Notice that deprecated
methods are marked with strikethrough (and deprecated modules are in imports
as well, though I didn't show that above).

Notice also that the documentation here looks better - it has links,
colors, etc. This is because NetBeans supports the reStructuredText
Docstring Format (see PEP 287).
System libraries are being documented in this way now, so more of the
documentation will start looking like this.

When NetBeans finds embedded code, it will also syntax highlight the
code fragments in the documentation:

You can use this in your own documentation as well obviously.
Here's a file where I have restructured text. As I'm writing it,
I can -immediately- preview the text myself by just pressing
Ctrl-Shift-Space (Show Documentation - for those who don't know, you
can do this on regular code as well if you want to just get the documentation
for the code at the caret, rather than completion alternatives up to
the caret prefix.)

Here's a final example - completion after raise (or
exception) will show completion for all Error
classes:

I'll be quiet or about a week now -- I'm going on vacation! Not great
timing given the release date, but this has been planned since February...

NetBeans Screenshot of the Week #35: Support for Python's all Variable

2008-11-13T06:32:00.000-08:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

Let's start with a pretty simple module - an import, a function, and a couple of classes:

(Notice by the way the semantic highlighting here - the unused parameters and variables are marked with a slight grey underline,
method names in bold, parameters in orange. More on that another day.)

Now let's go to a different file and import this module. Code completion is context dependent and shows us
which symbols are being exported by the given module. We see not only our functions and classes, the imported symbol sys
is also being defined by module, meaning that if you do from compl4 import * you would have sys defined as well:

Python has a way to deal with this: You can specify a variable named __all__, which lets you define exactly what the public API for
this module should be (more details).

Let's go in and define the names we want exported by our module. I will add __all__ = [ "Bar " ] somewhere in the file, to specify that only Bar should be exported:

Look at the file outline / navigator on the left hand side. As soon as I typed in the __all__ line,
the icons changed to show me that only the Bar class and its method are now "public"; there are little
lock icons on everything else! Let's see what code completion offers when we try to import this module again:

Yep, only the public API is exported now. Let's append to the __all__ list to export the func function:

You don't have to rely on icons to tell you if something is wrong though. Let's say I've forgotten all about this, and I decided
to rename my Bar class:

NetBeans checks that all the symbols you declare in your __all list actually exist, and points out any discrepancies. Here, the public Bar class no longer exists since we renamed it.

Here's another little bug I came across related to this. I was checking the __all__ handling on various library files,
in this case posixpath.py. Notice how in the navigator, all the functions are public, except one...

Sure enough, the code looks like it's registering this conditionally added method... Do you spot the problem? There's a dot missing!
As soon as we add it, we get this:

Of course, this last bug was already detected by the
unresolved symbol detector...

Ruby Screenshot of the Week #34: Detecting Duplicates Hash Keys

2008-11-12T10:50:00.000-08:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

You didn't think we had forgotten Ruby, did you? Here's a new Ruby editor feature: Detecting duplicate hashkeys. As "Fjan" (who filed the
request) says, when some Rails calls allow dozens or more keys, you can accidentally add a hash key twice, with subtle results. NetBeans now tracks these down and points them out for you.

This is going into 7.0, but you can use this 6.5-compatible module as well.

Martin and Erno have also been hard at work. There are many new features in 6.5 (which I'll cover when 6.5 ships in a week or two). But in the 7.0 trunk, the debugger can attach to arbitrary and remote processes - see
Martin's blog entry for more info. And Erno has added support for Shoulda testing and more test runner improvements - details here.

NetBeans Screenshot of the Week #33: Finding Unresolved Symbols

2008-11-11T01:23:00.000-08:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

In my last entry I showed that the Fix Imports action will alert you to an unresolved symbol. This is really helpful since it can help you track down runtime problems.

Obviously, you shouldn't have to go run Fix Imports on every file, periodically, to look for unresolved symbols!

NetBeans has a special semantic checker for this. It is off by default, for two reasons:

I added it just a couple of days ago - during the stabilization period for EA, so I didn't dare enable it in case it's seriously broken.
There are cases where it doesn't yet work. I'll describe that later.

To enable it, open up the Editor options dialog, and under Hints, select Python. You should now see the current batch of Python hints. Enable the "Unresolved Symbol" hint:

Now let's open up the datetime.py file again:

As you can see, the file is marked erroneous (by the red square above the scrollbar), and the scrollbar indicates where in the file the error is. Clicking on it to expose the error location you can see an underline under the unresolved symbol, and a tooltip explaining what the problem is. The error is also shown in the tasklist, so you don't have to open each file to look for problems - just let the tasklist scan your project for problems.

Here's another example. I opened up the Django 1.0 sources, and NetBeans pointed out this problem to me, in django.utils.simplejson.tool:

This shows that the import is unused, and that the attempts to call methods on the import do not work. The call would need to be changed to


obj = django.utils.simplejson.load(infile)

or the import changed to be


import django.utils.simplejson as simplejson

Here's one final one... Perhaps helpful to people having done a lot of Java development recently:

Finding unresolved symbols means that NetBeans must be able to find all the libraries you are importing. This means you can't just point NetBeans at a plain Python file - your project has to contain all the libraries you are using, and, you have to configure your source path correctly such that NetBeans computes the correct package names for your python modules. (I accidentally pointed to the "django" folder instead of its parent folder at first, which meant django. wasn't part of the package prefix and that meant that all kinds of symbols couldn't be resolved.)

Second, this won't work for dynamically generated symbols (eval etc). I haven't run into this a lot yet - but I'm sure there are areas where the unresolved detection can't find symbols that really do exist.

P.S. Is there a canonical Python term for what I've called "unresolved" here that we should use instead?

NetBeans Screenshot of the Week #32: Python Import Management

2008-11-10T14:03:00.000-08:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

We're about to release an early access release of Python support for NetBeans. We have ambitious goals for the Python support: NetBeans should be the best IDE for Python development, bar none!

Over the next couple of weeks I'll post screenshots of a bunch of editor related features for Python. Today I'll start with a feature near and dear to my heart: Import Management.

I used to be a die hard XEmacs user. When I started coding in Java, I continued using emacs for a couple of years. And the feature which finally made me abandon emacs for a Java IDE? You guessed it -- import management. If I wanted to use for example the List class, I could just press a keystroke to choose which List class I had in mind, and the import statement was added for it at the top of the file while I could continue working in the middle of the file somewhere.

To be sure, this is not rocket science, and Emacs support for Java has improved a lot over the years. But at the time, this was a huge productivity boost and coupled with other code-intelligence and navigation features was enough to lure my away from my comfort zone in the IDE to what was a less powerful plain text editor, but a more powerful Java coding tool.

Anyway, Python shares some similarities with Java. There are lots of libraries, and you need to import modules before you can use them. And this is where NetBeans' Python support can help.

Let's say I've tried calling the cmp method to compare files. I ran the code and realized I need to import cmp before I can use it. To get the IDE to import the symbol for me, I can just pull up the context menu and select Fast Import (or more realistically, just use the keybinding Alt-Shift-I):

This brings up an import dialog like this:

This tells us there are two definitions of a function named cmp - one in filecmp and one in functions. I'm interested in the first one. The label below the list tells me that I can hold the Alt key or the Shift key when I select the list entry to change the import statement. And below that, there is a preview of the import statement that will be generate. As soon as I press the Alt key, the window changes to this:

Here, the bottom line is showing that we will be doing a wildcard import of all symbols instead of just the target symbol. And finally, let's press Shift:

This will not just import the cmp symbol, it will instead import the whole module and change my current call to use the imported module symbol. When I press Enter my editor looks like this:

This is the import facility I ditched Emacs for ten years ago. But it's not how I manage imports for Java anymore. Instead, there is the Fix Imports action (it's also there in the menu -- Ctrl-Shift-I for short). Unlike Fast Import, which looks at the identifier under the editor caret, Fix Imports will look at all your imports in the file, and, well, fix them! This means sorting them, removing duplicates, even removing unused imports. And obviously, resolving imports automatically using the machinery I showed above. Here's how this works.

Here I've opened the SocketServer.py file, and then I've commented out all the imports:

The file is now broken - it has various references to functions that are not defined/imported anymore. Let's see what happens if I press Ctrl-Shift-I:

Tadaaa! It has figured out the missing imports and has inserted them. This is confirmed by a message in the lower left hand corner:

This just happened automatically because NetBeans could figure out, unambiguously, what the missing imports must be. Let's make it less clear-cut. I'm going to insert a call to get(). Now let's try again:

This time we get a dialog. You can see that it has figured out the sys and os imports - but it is not certain to do about the call to get(). There are two modules defining this function - unicodedata and webbrowser:

The corresponding function signatures are listed to help me decide which one I'm interested in. I can choose one of them, and when I press Ok, the imports are applied.

In some cases it may not find the symbol at all. Let's put in a bogus call:

Here the import manager can't figure out what to do - there is no known matching function. Only when NetBeans is certain about the imports does it proceed to clean up the imports without any user intervention.

This facility can also help find bugs! When I was testing this feature, I happened to invoke it in the datetime.py file which ships with Jython. Here's what it said:

That's right - the code is referencing nonexistent class ValuError. This clearly should be ValueError!
NetBeans has additional facilities for tracking down these types of bugs which I'll cover in another post.

So far I've focused on using the import facility to import new symbols. If you're writing code using the editor you may not need it, since when you use code completion to insert calls, it also automatically inserts import statements as needed.
However, another useful aspect of Fix Imports is cleaning up your imports: removing duplicates, sorting alphabetically (configurable), and even deleting unused imports.

If you open up a file with unused imports, NetBeans will show you that immediately:

There are quickfixes here, so if you click on the lightbulbs or press Alt-Enter, you can see the import actions:

The integration with quickfixes means that if you look in the tasklist, it will show files containing unused imports. But when you're editing, you can just press Ctrl-Shift-I to clean up the imports - it will do everything we've covered so far: Add missing imports, remove duplicates, remove unused, and sort the remaining imports.

Import management is also tied into source formatting. If you format your source, you can optionally have it clean up formats. Here are the formatting options for Python:

You can play with the checkboxes and the preview will show you the effect. Here's what happens if we enable sorting system libraries to the top. Note also that removing unused imports is not done by default during formatting (whereas Fix Imports will perform it automatically). You can change that in this formatting preference panel:

As I mentioned, we'll have an early access version out very soon. If you're feeling adventurous, you can always download builds from the continuous build server - http://deadlock.netbeans.org/hudson/job/python/. Please file bugs and ideas here.

Champagne!

2008-11-06T08:39:00.000-08:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

I'm extremely proud and relieved. If it hadn't been for the embarrassing passage of Prop 8, it would have been a perfect ending to the last eight years.

Mercurial Tip: Checking in regularly with uncommitted changes in your clone

2008-10-31T03:53:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

NetBeans, like OpenJDK and OpenSolaris, uses the Mercurial distributed version control system. I'm a big fan of of distributed version control. However, one thing that drives me nuts is this error message:


% hg merge
abort: outstanding uncommitted changes

This isn't just going to be a rant - I've finally found a solution which is working extremely well for me. I've suggested it to some other developers who have also reported that it works well for them, so I thought I would share it with you.

The reason I run into this all the time is my preferred style of work:

I like to work on many things simultaneously. If while working on something, I come across a bug and I spot the problem, I just fix it right there and add a test for it. When I get ideas, I might go and put @todo tasks for myself, or leave editorial comments in various source files. I might also work on a couple of larger tasks simultaneously. Yes, I know the preferred Mercurial idiom for this is to have multiple clones, one for each task - but that isn't my preferred way of doing it. Each NetBeans clone is huge and takes a while to both clone and build - and I would have to switch my IDE editing context between these large source trees all the time.
I like to check things in in logical chunks with a message that pertains to that particular change. This means I often check in a subset of the edited files in the tree.
I like to check in code regularly rather than leaving all files edited until I'm ready to check everything in.
I like to keep up to date. I'm using the bits I'm working on and I report problems when I see them so I want to make sure these are truly new and current bugs. Therefore, I update to the tip at least every day.

It turns out that the above requirements are tricky to fulfill with a default setup. Here's what happens.

I'm working on something and a high priority bug comes in. I find and fix it. I check in just the fix for this one problem. I
still have many other edited files in my clone since I was in the middle of something else.
Since it's a high priority bug, I want to push it. However, when I do, I get this:
```
% hg push
pushing to https://tor:***@hg.netbeans.org/main/
searching for changes
abort: push creates new remote heads!
(did you forget to merge? use push -f to force)
```
This tells me that somebody has checked in something since my last pull. That happens a lot with a project like NetBeans
where there are checkins every few minutes.

No problem - I'll just pull down their changes, merge, and push again, right?


% hg pull && hg update
pulling from http://hg.netbeans.org/main/
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files (+1 heads)
(run 'hg heads' to see heads, 'hg merge' to merge)
abort: crosses branches (use 'hg merge' or 'hg update -C')

Ah, I couldn't just update, I have to merge since I have checked in changesets of my own. Let's do that:
```
% hg merge
abort: outstanding uncommitted changes
```
!@#@%*#%$%&*$ ! Now, if I have dozens of changes, what do I do? When I first started using Mercurial, I would either
try to finish my other changes and check them in and then try the merge again, or if I really wasn't ready to do that,
I would copy the contents of my modified files to another location, hg revert the changes, and try again.

The Solution

It's really very simple: Use two clones. Do all your work in clone "main", and all your merging and pushing from clone "sync".
Let's say the main repository is "master", and your two clones are "main" and "sync":

To get set up, either clone the master repository twice, or, you can clone your main locally, but be sure to update
the "parent" reference in your sync clone such that it points to the master instead of your working clone
(I do that by copying main/.hg/hgrc to sync/.hg/hgrc.)

Here's the new workflow:

As before, work in main. Edit files at will, and check in logical changesets as needed.
When you want to push a changeset, go to your sync clone, and pull your new changesets from your working clone:
```
% cd ../sync
% hg pull ../main && hg update
```
At this point, it's best to try a build/test as well, to make sure changeset is complete. If you're working
on many things in parallel, it's possible that your changeset is depending on a change in a file you haven't
checked in yet.
Now pull in the new changes from the master, and merge these:
```
% hg fetch
```
(Or if don't have the fetch extension installed, do it manually - hg pull && hg merge && hg ci -m "Merge").
If something went wrong with the merge - no problem. You can just go and nuke the entire sync clone
and try again! Your modified files, and your new changesets, are still sitting completely unaffected in the main
clone. Just clone sync again and try more carefully :)
Now you can push your merged changesets to the master repository:
```
% hg push
```
...and now you can pull these changes back into your main repository:
```
% hg pull ../sync && hg update
```
This will give you all the tip changes into your working clone, but without the risk of causing multiple heads that you
have to merge. You've already merged your local changesets over in the sync clone, and therefore there is no
conflict between your local changesets and the new changesets in the tip!

Work in main, push and merge in sync, and pull back into main.

This is the reason I'm suggesting this approach to anyone using Mercurial, not just people who want to work with edited files.
Especially when you're new to distributed version control systems or Mercurial, it's great to be able to go back if you make
a mistake. Just make sure you know what you're doing before you submit that final hg push command to push everything
back to the master repository!

Find Memory Leaks!

2008-09-09T09:22:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

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).

Screenshot of the Week #31: Python, Groovy

2008-07-26T02:52:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

In my language support blog entry last week I talked briefly about the PHP, Python and Scala work going into 6.5. That's not an exclusive list. We're also adding Groovy support, and it's making great progress. Martin Adamek is posting status updates on his blog; here's Groovy instant rename in action:

The Python work is making good progress too. Here's code completion now for methods and classes, with integrated documentation support:

Here's another screenshot: Python quickfixes:

Anyway, I'm going on "vacation" now for a few weeks. I put that in quotes because I'm moving, and honestly, packing, cleaning and moving is hard work. Coding, now that's fun. I can't wait for my real vacation to start when I get back to work.

Multilingual NetBeans: PHP, Python, Scala

2008-07-15T03:30:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

I've mostly been writing about Ruby and JavaScript on this blog, but NetBeans is getting strong language support in other languages as well!

First, take a look at the PHP support. Petr Pisl, Tomas Slota, Radek Matous, Tomas Mysik and others have been posting screenshots and
feature descriptions regularly on their team NetBeans PHP blog. Check it out - code completion,
quick fixes, semantic highlighting - we're going to have a fantastic PHP IDE! Here's a screenshot - look at the unused method detection for example:

The Python support is starting to shape up too - here's a screenshot of code folding, semantic highlighting and instant rename refactoring.

Coming soon - code completion and other editing goodies.

And I just now noticed a post from Caoyuan Deng
that his Scala support for NetBeans is now built on top of the native scala compiler. His editing support is already feature packed (take a look at his blog for some of the past entries) and now that he has 100% language parity things are looking very very good!

Last but not least: InfoWorld has reviewed 9 Ruby IDEs,
and NetBeans came out on top!

Ruby Screenshot of the Week #30: New YAML Editor

2008-07-06T15:11:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

As part of our Ruby and Rails support, we've had a YAML editor in NetBeans for a couple of releases now. However, the support was primitive. Only the most basic editing features were there, and more problematically, many common, valid YAML constructs were not supported. You'd get various wrong error messages from the parser if you tried to go outside the normal simple syntax of the database.yml file in Rails.

In the latest dev builds however, there's a brand new implementation of a YAML editor. Let's start with a screenshot:

There are several things going on here. First, note that the editor now understands more complicated YAML constructs - such as the << key mapping merge operator. In this file, we've shared the definition of the "createdon" attribute. And in the navigator, as we drill down you can see this attribute showing up properly inlined in both places the reference was used.

Notice also how we have embedded Ruby code here (the green fragment inside <% %>). This is pretty important for another Rails usage of YAML: Fixtures. Just like in ERb/RHTML files, the YAML Ruby embedding support should be complete; quickfixes should work, go to declaration, smart indent and formatting, and so on - including code completion:

Finally, if you're a bit rusty on YAML and can't remember all the various escapes to do collections, aliases, documents, tags and so on, you can invoke normal code completion to see the various special characters - along with the YAML quick reference document in the documentation popup:

There are a few other things in there as well; AST based selection (Command-Shift-Dot or Comma), slightly better smart indent, and so on. One thing which is still missing is code folding. I disabled it since there were a few issues with it still.

I have to pause here and add a big Thank You to Ola Bini from the JRuby team! A few weeks ago, yet another bug report was filed by somebody complaining about a false error in the YAML support, and I decided to look into rewriting it from scratch using the same editor infrastructure that we have for Ruby, JavaScript, etc. The first thing I would need however is a YAML parser. I know JRuby had a good one, so I tried using it - but realized I would need to customize it a bit for IDE purposes. For example, I would need AST offset information. I thought of ways I could subclass parts of the YAML parser to achieve this, and I sent an e-mail to Ola asking if he thought this was feasible. I immediately got a response - and not only did he say it was possible, he offered to personally do it, by adding proper offset support into the parser. And just a couple of days later he released a new version of the parser with full offset support. It worked perfectly. With the parser in hand, implementing the above editing functionality was easy. So a lot of the credit for the new editor goes to Ola. Thank you!

As always with new functionality, please take it for a spin and report back any issues you find (using the normal feedback channels). NOTE - you do need the latest dev builds for this - even 6.5 Milestone 1 is too old. Some of this was checked in today so won't even be in the current nightly build (depending on when you read this).

Ruby Screenshot of the Week #29: Test Navigator for RSpec

2008-06-24T05:20:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

Let's start with the screenshot:

The thing to notice here is that we have a number of RSpec do-blocks in this file. Until now, only classes, methods, fields and attributes were showing up in the navigator. But in the latest daily builds, rspec do blocks like these are shown in the navigator (bottom left corner), along with the string summary (if any) such that you can quickly navigate between them. Placing the caret in one of these blocks will highlight the corresponding item in the navigator.

Adding a better navigator outline for spec files has been on the TODO list for a while, but apparently in the latest Rails builds regular tests are also switching away from using test methods to using test blocks (according to issue 137925, thanks James). So it seemed high time to do something about this.

The other thing to notice is that these blocks are also folded, so you can use Command-Shift-+ and - to collapse/expand all blocks quickly.

By the way, another old issue was fixed in NetBeans recently, which makes it easy to configure filetypes. In the past, if you wanted say .mab files to get Ruby treatment in the IDE, you'd file an issue and I'd modify the Ruby mimetype resolver to include it. The list is already pretty long -- .rb, .rake, .rxml, .rjs, .rbw, .rbx, .mab, .builder, .gemspec, and so on.

Now you can add any extra types you want yourself, using the Options | Miscellaneous | File Associations. Add any extensions you want, and bind them to the Ruby mime type and all the various Ruby editing machinery should kick in for files of that type.

NetBeans 6.5 Milestone 1 is about to be released and there are a lot of goodies there - both in the Ruby specific featureset as well as generic IDE support (such as the new Quick Search functionality). I'll look into that for another entry. And apologies for the long delay since my last entry - I blame it on a combination of having been sick, having taken some time off and having been busy with work...

Ruby Screenshot of the Week #28: Unit Testing, and Color Themes

2008-05-29T14:06:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

NetBeans 6.1 has been out for a while, so we're working full steam ahead on NetBeans 6.5. There are a number of new features in the trunk, and I'll show a couple of them in this post. First of all though - if you have found ERB or RHTML file editing slow in NetBeans 6.1, please try NetBeans 6.5. There was a performance bug where if you have a lot of JavaScript files in your public/javascript folder, RHTML editing gets really slow. A fix for this will be released, but it didn't make it into Patch 1 so it will be addressed in patch 2. But the daily builds of NetBeans 6.5 has the fix, so if this bug is affecting you, please try the dailies instead. And as a side benefit, you'll be able to access the following features:

New Unit Test Runner!

Erno Mononen has written a new Test Runner UI. In 6.1, unit tests were just run and the normal output shown in the Output Window with some hyperlinks. In the new dedicated test runner, you get something similar to the JUnit window we've had for a file for Java. (Click on image for full size)

Be sure to run your test classes as tests (e.g. use Ctrl/Command F6 rather than Shift F6) such that the IDE will run your classes under the testing GUI. This works not just for Test::Unit but for RSpec as well. You can get more details about this in Erno's blog entry, and if you run into issues, please let us know.

The Aloha Color Theme

Mike McKinney has created a really nice dark color theme for NetBeans, called Aloha. I've taken his theme and have integrated it into our "Extra Color Themes" plugin which is available from the Daily Update Center (and soon, the Stable Update Center). To install it, get the plugin, and then go to the Options dialog and choose Aloha under the Fonts & Colors category. You can see more screenshots of Mike's theme in his blog entry. In previous releases we had some problems with CSS and JavaScript colors not being customizeable, but that is not a problem as of NetBeans 6.1 so hopefully all the file types look great. We still need to make the version control diffbar and the debugger breakpoint and current pc lines respect the current theme; hopefully we'll get to that in NetBeans 6.5.

By the way, you may notice that you only see the editor here. When you press Shift-Escape, the current window with focus gets maximized. I do that while editing a lot. You can press Shift-Escape to toggle it back - and you can also temporarily open the other windows (which you can see slide to the edges) by just hovering the mouse over them.

Finally, one minor feature which can come in handy in NetBeans 6.5 is that "Mark Occurrences" now has a keyboard shortcut for navigating between the references. Thus, if you put your caret on some symbol, you've probably noticed that it gets highlighted - along with other occurrences of that symbol in the same file. You can now use Control-Up and Control-Down to jump between these references. Pretty handy.

Oh, and one more thing - JRuby 1.1.2 was released a few days ago and NetBeans now bundled it - along with RSpec 1.1.4.

JavaOne 2008

2008-05-11T12:56:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

JavaOne 2008 is over. As usual, it was a great event, but with the stress and hard work leading up to the conference, it's a huge relief that it's all over. For my part, it was another extremely busy JavaOne, with two keynote demos, a technical session, a panel discussion, a BOF, as well as three presentations at CommunityOne the day before. If you add to that the prep time for these (keynote software setup and rehearsals, slide planning etc.) there was barely time for anything else, so despite my best intentions I didn't get to meet up with a lot of the out-of-towners visiting JavaOne that I had planned to. I only made it to three technical sessions - and in all three I learned something. Hopefully the rest of the sessions that I missed had the same high level of quality.

I was interviewed by the JavaOne paper on Wednesday; the online interview is here. If you read my blog you might find it interesting. However, in the paper version of the interview, something went horribly wrong... Some of the questions and answers attributed to me were from a previous interview! In particular, I'm found endorsing the Flex SDK, as well as talking about my "math background". Those parts were from the previous day's interview with Chet Haase!
If you're wondering why I'm referred to as a "Rock Star" in the interview, that's a JavaOne thing. The top 20 highest rated talks each year (as determined by the speaker survey forms collected for all talks) earn their speakers a lifetime "Rockstar" title at JavaOne. And speaking of Rockstars, I've got independent verification that I am one (wink, wink) since Ed Burns also interviewed me (and the other JavaPosse guys) for his Secrets of Rock Star Programmers book. The interview was conducted a year ago, but the book is out now. I've read some of the chapters already and really enjoyed it.

It's always exciting to be part of the keynote demos. It's a huge production with over 10,000 people in the keynote hall. A lot of work goes into it. There's a control room in the back, NASA ground-control style. Arun Gupta snapped a few pictures during rehearsals this year and posted them here. The 10th picture gives a sense of the size of the hall. On the left is a drawing one of my kids drew of how she imagined my keynote demo - it would be nice if we actually had chairs to sit on. I guess when you're a kid you wouldn't imagine standing up while doing things on a computer! Anyway, you can see the webcasts from the keynotes - they are all available here. In particular, you can see our Tic Tac Toe demo here (about 2:20 into it), and the JavaScript editing demo here (about 19:45 into it).

The Java Posse BOF was another highlight for me. We had a short appearance at CommunityOne, but with just 20 minutes we didn't quite get into the groove. Thursday night for our BOF however, and with beer, we had a great atmosphere. We had feared a really low turnout since our BOF was scheduled smack in the middle of the Smashmouth concert - but that turned out not to be a problem, either because it was cold outside, or because a lot of people hadn't heard of Smashmouth (think the movie soundtrack from Shrek), or perhaps because we have really loyal listeners! If so, thank you!! A contingent of Norwegian listeners came up and handed us a lot of Norwegian chocolate! I didn't catch your names - but thank you very much! My local gym also thanks you...

My brother (who also works at Sun and has his own blog) has been staying with us for the last month - first for the MySQL conference in April, then JavaOne. It's been great having him here. We tried to get him on the air in one of our podcasts, but he refused - so instead we embarassed him during our BOF with a dedicated slide and tribute! He headed back to Norway this morning; Trond, it's been great to have you here and welcome back.

I'm taking a few days off now to catch up on sleep and chores!

JavaScript Type Inference in NetBeans

2008-04-29T07:03:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

Roman Strobl has just
published a screencast of the new JavaScript editor in NetBeans 6.1. The demo is around 5 minutes and highlights many of the editing features.

I'd like to dwell on the type inference part a bit. Around four minutes into the demo, Roman shows that NetBeans figures out the types of expressions, including those involving function calls. In his example, all the types happened to be Strings so it may look like a lucky coincidence. It's not! Here's some code fragments showing in more detail what's going on. Let's start with a jQuery expression in an HTML file - in my
last entry
I showed how code completion already
helps you fill in the strings inside the jQuery dollar function. NetBeans knows the return type of the dollar function so we're only presented with jQuery methods here:

jQuery methods return the jQuery object itself as the return value, so we can chain calls into jQuery. We'll do that here by calling a function on the return value from addClass:

As you can see, when NetBeans knows the return type of a function, it's shown in code completion item separated by a colon. Here I want to call the queue() method which returns an array of functions. Let's see what happens if we just call functions on the result object:

As you can see - we're getting methods on the Array class, since we're getting an array back. Let's pick a specific element in the array instead, and see what code completion gets us:

As you can see it knows that this must be a Function, so we get for example the apply method suggested. (Put another way, we're tracking internally the type of the elements within the array.)

At this point you may wonder where these types come from. JavaScript is not a statically typed language, so what gives? It turns out that while JavaScript isn't typed, a lot of code is written with specific types in mind, and in fact there are a lot of documentation conventions for declaring the intended types not just of function return values, but of parameters and properties as well. NetBeans understands many of these - such as @param {Type}, @return {Type}, and @type. Here's a new function we've added in the editor which declares a return type:

As you can see, when we try to invoke code completion on the return value of this function, it's using the return type we specified - the Date class.

However, it doesn't end there. In many cases, NetBeans can also figure out the type without it needing to be explicitly specified. Here's a function without a type declaration, yet NetBeans knows what to do with the return value:

This is an area where the type handling in NetBeans is currently better for JavaScript than for Ruby. Ruby doesn't have the same convention of documenting types for libraries. In fact, many Rubyists feel that this would be counter to what Ruby is all about: Methods shouldn't know what the types of the parameters are - all that matters is what the objects respond to the required method names used by the function. However, for people who -want- IDE help, improved type documentation could certainly help. And NetBeans understands some Ruby type assertions for parameters:

There are several efforts to allow type hints for Ruby. For example, Charlie Nutter's Duby project uses type hints to generate more efficient bytecode for Ruby execution - and the same hints could be interpreted by the IDE to assist with code completion, go to declaration, etc.

Finally, as the last JavaScript screenshot shows, there are many cases where it's easy to figure out what the return type will actually be for the current implementation of the method. That's an area I want to look into next, such that I can apply the principles I've applied for JavaScript to Ruby as well. Fun times ahead!

Let me finally apologize for my tardiness in responding to e-mail, blog comments, newsgroup posts etc. We're just a week away from JavaOne, so work is extremely hectic at the moment. But it's going to be a blast as always! I hope to see many of you there - please say hi!

P.S. I've been fixing quite a few bugs in the JavaScript support since the 6.1. code freeze. I'm hoping to get it all rolled into an AutoUpdate patch. If you're running into problems with 6.1, please give the daily builds a try! By the way, Martin Krauskopf just integrated (into the daily build) a new Rake Runner for Ruby!

Screenshot of the Week #28: NetBeans + JavaScript = True!

2008-04-04T07:55:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

Apologies for my low activity on this blog recently. I've been swamped during the NetBeans 6.1 development cycle.
The main reason is that I've been completely consumed reimplementing the JavaScript support in NetBeans. It is
now built on the same infrastructure as the Ruby editor. It's been quite a sprint to get it done, but we're
about to freeze NetBeans 6.1, and it's in. And I think NetBeans now compares quite favorably against other JavaScript
IDEs and editors.

Does this mean I've moved on from Ruby, and the NetBeans Ruby support is now in maintenance mode?

Far from it! Not only did we double the size of the NetBeans Ruby team from 6.0 (when Martin Krauskopf and myself
were the team); in 6.1 Erno Mononen and Peter Williams joined us. And I'm still in charge of and working on the
Ruby editor - which in 6.1 adds complete Rails 2.0 support (and Rails 2.1 - I just yesterday integrated support
for the new UTC timestamp migrations), as well as
a bunch of new quickfixes, and tasklist integration, etc.

However, a lot of the work I've been doing has been on the editing infrastructure, which benefits
Ruby directly. For example, in NetBeans 6.1, the long file indexing process which would happen on every IDE startup
now happens only on the first startup. And more importantly, we're much more robust now in handling complicated
embedding scenarios in ERb/RHTML files. Where in 6.0 we had a lot of custom code to handle ERb specifically,
the generic language embedding support we have now means that most Ruby (and JavaScript!) editing features work
automatically and correctly in ERb files as well. So features like mark occurrences and semantic highlighting
which were not available in 6.0 now work in ERb files as well for Ruby.

My main motivation for working on the JavaScript editor was that we often got the feedback
from NetBeans Ruby users along the lines of "I love your Ruby editor, but my Rails application also needs JavaScript,
and I go to other tools for that". We want NetBeans to be a complete editing solution, and JavaScript is obviously
vital for any web framework, including Rails. Therefore, to be a top notch Ruby IDE, we have to have top notch JavaScript
editing as well.

So what are the new compelling JavaScript features in NetBeans 6.1? I'm not going to show everything here, but here's
a Rails-focused introduction to some of the features.

First, let's create a new Rails project. Then I open the public/javascripts/prototype.js file that ships with Rails (click for full size):

First, take a look at the semantic highlighting. Prototype-style method definitions are bolded. As with Ruby, unused local variables, parameters and catch scope variables etc. will be detected and underlined. And NetBeans figures out the scope of variables and shows you global variables in a different color (green, but that is obviously configurable). This helps you find cases where you perhaps have a typo so instead of referencing a local variable, you're accidentally trying to read a nonexistent global variable. Or, as is the case in this screenshot, they were probably accidentally declaring a global variable:

I doubt that the intention for this function was to leak out a new variable named position; the intention was probably to have included a var keyword here to make the loop variable local like this:

Let's move on to the quickfixes. Take a look at the vertical scrollbar on the right - here it is again (flipped horizontally) :

Each little yellow mark corresponds to a quickfix warning NetBeans has added at roughly that position in the source file. The tasklist view lists these such that you can sort by type. (This isn't some doctored up testcase file to exercise the quickfixes - this is the standard prototype.js file.)
Every quickfix type can be disabled - and they also offer links to more information about the error. Here's the warning for multiple return values:

The mark occurrences feature lists all the exit points of a function when you place the caret on top of the corresponding function keyword. Here you can see that we have both a plain return; with no return value, as well as another return with a value. How would a caller of this function treat the return value of this function?

There are a lot more detectors, which I will describe in a future blog post. Now, let's open the default index.html file that ships with Rails. Here's code completion on the Prototype $() function:

As you can see, it uses the HTML parse information (this is part of the language infrastructure I talked about earlier) to locate all the element ids in the document and offers those as completion. As you can see it includes those ids that were accessed by Rails' own $-calls for the lines above.

Code completion also works with the Prototype $$() function, which performs CSS selections. First, show the used element types in the document:

Then filter on the HTML element classes in the document:

There's just one - from a few lines later:

We can also filter on the many CSS pseudo classes:

This post is already getting long so I won't get into all the JavaScript features now.
Here's a blog entry somebody
else wrote with some more features and screenshots. The main point of this blog entry was to explain why
I've been so busy, what's in store for NetBeans 6.1, and to reassure you that NetBeans Ruby and JavaScript support
is going to continue developing at rapid clip. Code editing is a top priority for NetBeans!

Feature Comparisons

2008-03-13T02:17:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

Aptana RadRails just shipped their 1.0 release. Congratulations!

One thing that spoiled things a bit for me is the
Feature Comparison matrix they posted on their website. Along with the predictable green column for RadRails, they have red X's next to a lot of features in the NetBeans column. Features that definitely are there in NetBeans (and in some cases I would argue more so than in Aptana).

If you're going to post a feature comparison I think it's a bit irresponsible to do so without actually checking what the competition offers. NetBeans is free (and no registration is even required), so it's easy to download to check, and if you don't even want to do that, just google "NetBeans Ruby" which will point right to our Wiki which has extensive feature lists listed right on the front page.

(Update: Their feature matrix has been updated, and now recognizes that NetBeans does in fact offer RHTML editing, YAML editing, and XML editing.) There are however a number of errors remaining. Here are some of them.

Yes, we have a JSON editor (and ours is free)
Yes, we also have TextMate templates (templates for Ruby,
RHTML)
Yes, we have Extract Method (Details)
Yes, we have Extract Constant (and we have Extract Variable and Extract Field as well, plus a number of other refactorings tied to the caret, listed in the RubyHints wiki page.) (Details)
Yes, we have RHTML code completion. (Details)
(This isn't really for the feature comparison since we don't ship it by default, but a regular expression tester is available for NetBeans as well - see this video for a tour.)

A green checkmark versus a red x seems a bit simplistic; not all feature implementations are equal. For code completion for example, there are factors such as how complete it is, how good the documentation markup is, parameter tooltips, whether completion helps you with hash keys, whether you get active record database field completion, and so on.

I'll forward this to their feedback alias so hopefully the page can be corrected. I'm trying to make the point to anyone else out there who is planning to make a competitive matrix: If you haven't actually checked, use a question mark rather than a red x for features from the competition.

Well, with that out of the way I don't want to rain on their parade; it's great that we have competition in the Ruby and Rails toolspace, and a 1.0 is a big accomplishment. Congratulations!

Roundup Roundup

2008-03-07T01:52:00.000-08:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

style="margin-left: 5px; margin-bottom: 5px" />

It's Friday morning and I've spent whole the week in beautiful Crested Butte in the Rocky Mountains, Colorado. Today is the last day of the
Java Posse Roundup 2008, the second time we're hosting this open space conference. It has been a blast!

The format is 4 hours of open-space discussions every morning, then skiing in the afternoon, and then we have "lightning talks" in the evenings - 5 minute quick presentations that are short enough that the speaker is forced to be concise so the presentations are always interesting.

Last night we also passed around the microphone and recorded conference impressions. Dick has already mixed it and uploaded it as the latest episode -
Episode 168. We've obviously
recorded all the technical sessions as well and those will be posted to the normal Java Posse podcast feed over the next couple of months. I believe Joe and Dianne also recorded the lightning talks with a little video camera and those will be posted to our new
YouTube channel.

Just like last year, a huge part of the success is due to the great set of participants. With so many different points of view and insights, every single session I've attended this week have been stimulating. While most of the participants came from the US, we even had 4-5 people attending from Europe! Stephan Janssen from the Belgian JUG has posted his pictures
here - the following picture is his. Notice the amount of snow we had!

The following photo (by Matt Zimmer) is from one of the lightning talks:

Again notice the snow outside the windows. The lightning talks might be my favorite - 15-20 quick presentations back to back on subjects ranging from techy things like
literate programming plugins for OpenOffice, Scala refactoring and JavaFX and Flex demos, Quantom Gravity and quantum cryptography, to Anime,
to Stephan showing us the Java Polis artwork (which I've talked about
before), and not just the ones that made it -- the ones that were rejected as well!

Some other coverage from O'Reilly's Chris Adamson
here
and here,
Ido Green
here
and
here,
Joe Nuxoll, and
Chris Maki.

Why Your JavaOne Submission Was Rejected

2008-02-01T04:59:00.000-08:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

JavaOne submission acceptance letters - and rejection letters - starting going out last night. This year, I was on the review committee for one of the tracks, so I got to see the proposals as well as the reasons for rejecting many of them. I thought I'd write these up, both to explain to the many submitters what might have gone wrong, as well as to give some tips for how to improve your chances next year. I'll probably link back to this post around the time submissions for JavaOne 2009 open up later this year.

Not Enough Details! There were a number of submissions that sounded interesting, but didn't include enough details for us to judge whether there is enough technical meat behind the promises. If you're promising insights or "lessons learned", tell us what those lessons are, such that we can judge whether your presentation will be worthwhile (and in particular, whether to choose your submission over the handful of other similar submissions in the same topic area).

Wrong category! I was on the Tools and Languages track. You wouldn't believe how many submissions to our track
were not related to tools and languages. Framework, Practices, Process or Methodology: If any of these words are in your title, make sure you're really explaining how this is going to be tool related or language related.

So why can't we just reassign them to the right track? Well, each committee works independently, and if we were to suddenly have to accept "new" proposals that were miscategorized earlier that would increase the work a lot - we've already gone through and picked our top candidates for each subject area and so on.

Not of General Interest! If you're submitting for a technical session, rather than a BOF, the talk will be offered in a room seating hundreds and sometimes thousands of attendees. The subject needs to be interesting to more than 20-50 people. If you're proposing a talk on a subject that is extremely narrow or a tool or language that doesn't have a lot of traction yet, you'll have better odds submitting the talk as a BOF.

Crowded Topic! Some topics are extremely popular. We received a large number of submissions for Groovy and Ruby for example. This means that if you submitted talks in one of these areas, even a perfect abstract wasn't enough and the choice for the committee was very difficult.

Strong Competition! At the end of the day, we only had about 20 technical sessions to hand out. We had more than ten times that number of submissions. We had roughly 10 talks for tools, and 10 talks for languages. Let's take languages - there's Groovy, Scala, Ruby, Jython, Java, ... as you can see there's not room for more than one or at most two talks in any one topic area.

The good news is that this hopefully means we'll have very high quality for the technical sessions!

Finally, work one one strong submission rather than submitting 5-10 half-baked ones; just adding lots of abstracts does not help your odds given my points above about the low number of available slots; each submission has to be fantastic.

Ruby Screenshot of the Week #27: Task List

2008-01-18T10:03:00.000-08:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

I've posted a number of blog entries showing NetBeans quickfixes for Ruby. This helps you detect problems in code you happen to be working on, since it shows a yellow rather than green file status if there are warnings in the file. (The file status is shown on the right hand side of the editor pane, next to the vertical scrollbar).

Unfortunately, this doesn't give you an easy way to audit your code. If you want to find all potential problems in your code, you'd have to open each and every file and look for yellow editor annotations... Not a tempting task for projects with hundreds of source files.

No more. As of the latest NetBeans 6.1 development builds, the Ruby hints and quickfix functionality is integrated with the tasklist. All you need to do is open the tasklist window (Ctrl/Command-6 - the number, not F6, or find it in the Windows menu). The tasklist will scan the entire project - or indeed all open projects - or even just the currently edited file. The tasklist scope can be chosen by the toggle buttons on the left hand side of the window.

When you're working your way through the results, note that the tasklist responds to the Navigate | Next Error action (default bound to Ctrl/Command-Period). This will also warp the caret right to the editor location for the error, which means you can press Alt-Enter immediately to show the rule quickfixes, if any. One such quickfix is to disable a particular hint type, so if you don't like a particular warning you can suppress it by just turning off the rule.

I personally don't like the Output window occupying the entire IDE width. Luckily configuring the window layout is very easy - just drag the windows around to where you want them. In my preferred configuration, I drag the output-windows into the editor bottom such that you end up with a layout like this:

Note also that the tasklist isn't only hooked up to the quickfixes; it's hooked up to the error functionality too and any parsing errors in your project will be listed there, at the top of the list (since errors have a higher priority than hints and warnings).

Although you can disable hints as I've described above, you cannot turn off compiler warnings yet (such as the one about ambiguous parameters).

Anyway, I hope this will be helpful. Even if you're not a NetBeans user, perhaps you can try a quick audit of your source code with it. Get a 6.1 dev build here, open the IDE, choose "New Project", and then choose either a Ruby or a Rails project with existing sources. Point to your sources, hit Finish, and then open the tasklist and let it churn away. Send bug reports and other feedback here.

Ruby Screenshot of the Week #26: Ruby 1.9 Changes - hashes and case statements

2008-01-05T04:36:00.000-08:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

Ruby 1.9 has been released. It's a "development" version meaning that you wouldn't want to use it in production, but now is a good time to learn the new ways of doing things such that migrating to Ruby 2.0 will be easier.

Via Ruby Inside, I read
James Edward Gray's recent blog entry
detailing the work he did to update his library to 1.9 - and a number of people leaving comments are also pointing out language changes.

One such change mentioned is case/when statements not allowing colon as a separator. (I don't see this in Ruby Changes Wiki - does anyone have a source for this?). Seems like a a good candidate for a Ruby quickfix:

There are a couple of available fixes:

The first one is just replacing the colon with a then:

The second fix is instead putting the statement on a separate indented line:

Another language change I found in Sam Ruby's post is that you cannot write hashes as lists anymore. Here's a quickfix for that - first the code, this is from webrick's httpstatus class:

The quickfix is attached to the first list entry in the hash:

And previewing the fix shows the following proposed edit:

As usual, the NetBeans Ruby forums can be accessed via Nabble here and Gmane newsreaders here (other feedback channels here).

Ruby Screenshot of the Week #25: require_gem

2007-12-20T04:17:00.000-08:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

There have been a number of releases lately. Rails 2.0 shipped. NetBeans 6.0 mostly supports it. There were a couple of changes, such as the scaffold generator's parameters changing meaning, and the new shorthand migration syntax, which affected NetBeans. I've committed changes to 6.1 to support these, so grab the latest if you're wanting complete Rails 2.0 support. However, note that we're in early 6.1 development so there's some big potentially destabilizing changes, such as a new platform manager which lets you choose per project ruby interpreters, configure separate gem repositories and so on. I'll post more about this when it's done. You don't need to upgrade if you're just wanting to use Rails 2.0 - nearly everything in NetBeans 6.0 works just fine.

JRuby 1.0.3 also recently
shipped, and I've just updated NetBeans 6.1 to use it. JRuby 1.0.3 lets you run Rails 2.0 without needing to install the optional jruby-openssl gem.

I just noticed that RubyGems 1.0 has
shipped. One of the changes in RubyGems is that the require_gem method, which has been deprecated for a while, is now gone - so you have to update your code appropriately. require_gem was used by previous versions of Rails, so many boot.rb files still reference it.

I just added a checker for this:

It's not just a warning - it's a quickfix:

The "Show More information" fix opens the browser on the release page for RubyGems 1.0 which briefly mentions the require_gem removal. If anyone has a better URL to an official and mostly permanent page (e.g. preferably not somebody's blog) discussing this change, I'd appreciate the link.

Ruby 1.9 is getting closer. Charlie recently
pointed out to me that they recently
decided that retry statements will as of Ruby 1.9 only be allowed inside
rescue blocks. Thus, we now have a hint to look for problems of this sort.

If anyone has
any ideas for other Ruby 1.9 migration issues, please
let us know!

Finally, let me end with a couple of links. The "Off The Line" blog has posted
cheatsheets for the NetBeans Ruby support, PDFs that summarize key shortcuts and other hints. And Michael Slater, one of the early adopters of the NetBeans Ruby support, will be offering a Rails Seminar in a couple of months, which is going to be using NetBeans. W00t!

Updated a few hours later: Dr. Nic pointed out that require_gem can't
just be replaced by gem and showed me how the code needs to be morphed. I've updated the
quickfix to do The Right Thing now - thanks Dr. Nic!

Ruby Screenshot of the Week #24: Quick Fix Previews

2007-12-03T03:21:00.000-08:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

First of all, NetBeans 6.0 (final) was released this morning. Go get it!

So let's talk about 6.1 :) I just updated the quickfix infrastructure such that we can automatically generate previews for how the hints will modify the source. I've also added some new hints.

Let's start looking at the user.rb file in the sample Depot application. If I place the caret inside one of the if blocks, a lightbulb appears:

NetBeans offers to replace this if-block with one where the "if" is a statement modifier. This idea came from the excellent "Exploring Beautiful Languages"
blog
by Luis Diego Fallas, where he implements NetBeans Ruby hints -- in Scala!

Here's the new preview functionality in action; instead of just applying the fix I invoke the Preview and get the following dialog which shows what the fix will do:

Preview is particularly useful for larger source changes like Extract Method.

Here's another method from the same file:

Obviously, we can apply the same "convert to statement modifier" here, but look at the first suggested fix:

NetBeans will convert "if negative condition" to "unless", and "unless negative condition" to "if" to make the code more readable. This was also shown by Luis in his blog entry. Here's the proposed fix:

and we can apply the other conditional cleanup as well to end up with a much simpler statement:

There is one more recently added hint: Check for accidental assignments.

At first I got a lot of false positives for this hint, since many Ruby programmers seem to like to intentionally assign in their conditions. But then I updated the rule to only complain if the variable being assigned to had already been seen in this scope, and that seems to do the trick perfectly. Newly assigned variables are intentional side effects of the assignment, and assignments to existing variables are likely bugs and should be avoided.

Quick Hi

2007-11-21T08:14:00.000-08:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

No screenshot-of-the-week this time; I'm taking the week off since the kids are out of school for whole the week. I'm having a lot of fun!

Meanwhile, Cindy Church has been busy creating more demo videos on netbeans.tv:
First, there's the classical

weblog tutorial,
and then there's showing how to

write and run unit tests in the IDE (where I'm incidentally also
using the Dark Pastels color theme I've discussed previously on this blog). We recently met and
recorded more material, so there are more screencasts in the pipeline. P.S.: Both screencasts are also available in higher definition as downloadable Quicktime files - see the "QuickTime format of this screencast" hyperlinks near the bottom.

Ok, back to vacation!

Ruby Screenshot of the Week #23: Extract Method and More Refactorings!

2007-11-12T04:15:00.000-08:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

Last week I promised to catch up on my e-mail, but I had been missing feature work too much during the bug phase so I put it off for a week... to implement some more quickfix refactorings:

Extract Method

Introduce Variable

Introduce Constant

Here's how it works. Let's start with "Extract Method". You're looking at some code like this:

You decide there's too much going on in this method, and you want to pull the middle section into
its own method. Select it, and notice the lightbulb which shows up on the left:

Press Alt-Enter to show the quick fix alternatives:

Select Extract Method, and the IDE will pop up a dialog asking you for the name of the new method you want to extract from the selected code fragment:

Press OK (or just hit Enter), and the code will mutate into the following:

There's a lot to notice here. First, there's a new method, and the active selection and caret is on a comment for that method (so you can just type to replace it). The new method is added below the one you extracted code from. And the most important part about this refactoring is that the IDE figures out which variables to pass in to the method, and which variables to pass back out:

a, b and d are accessed from within the fragment, so they are passed in.
c is reassigned in the fragment without reading the previous value, so
doesn't need to be passed in.
f and h are assigned locally inside the extracted fragment, but are not read
outside of it, so do not need to be passed back out
g is assigned inside the fragment, and read later outside, so it is returned
from the new method but not passed in
h is assigned inside the fragment, and is read later, but it is assigned
before this read access so the value doesn't need to be passed back
i is also assigned inside the fragment, and -may- be read after the fragment,
so it too is passed back out

Ruby's multiple return values makes this refactoring much cleaner than in Java where you have
to jump through some hoops to extract code fragments that modify multiple local variables...

Now let's take a look at Introduce Constant. Let's say you're looking at code like this (unlike the above contrived example from one of my unit tests for Extract Method, the following is from
the standard Ruby Library's Date class):

There are a lot of "magic" numbers here. I honestly don't know what some of them are - but I recognize 365.25 as the number of days per year. Let's make that clearer - select that constant. (Tip - just move the caret to it and press Ctrl-Shift-Dot, which selects progressively larger logical elements around the caret). This produces the above lightbulb, so let's press Alt Enter again:

I can now choose to either introduce a field, or a variable, or a constant. A constant is most natural here. (You won't be offered constant if the selected code fragment is not a constant expression.) So choose Introduce Constant:

In the dialog asking for the name of the new constant, notice that it also detected some duplicates of this constant in the same class (3 of them to be exact), and asks if you want to replace all of them. I do - so I select the checkbox and press Ok:

The IDE has inserted a new constant at the top of the class, and has warped to it to let me edit a comment for the constant. I can also scroll down and see that the constants below were updated:

The search for duplicates only looks for single constants at the moment, not more complicated expressions - it will do that soon. As always, please report any bugs you encounter. This is in the daily 6.1 trunk builds, although I've deliberately kept the code 6.0 compatible such that I can put this out on the update center for 6.0 as well.

Ruby Screenshot of the Week #23: Open Type and Open Method

2007-11-05T08:29:00.000-08:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

As of 20 minutes ago, NetBeans 6.0 entered high resistance, meaning that from this point on, only critical "showstopper" bugs will be addressed. We're spinning a release candidate in a a week, and after repeating that once or twice, NetBeans 6.0 will be done!

It's been a long sprint getting to this point, including last minute bug fixing. We took the kids to the waterfront in Berkeley yesterday where they had a blast with bugs while I blasted bugs (see picture on the left).

My e-mail inbox has been suffering the last couple of months. On the right is a snapshot of the sidebar in my Mail tool - the numbers listed next to each folder is the number of unread mail in that folder... As you can see, the number of unread mails addressed directly to me is a lot lower than in other categories (such as commit bug report mails) but even there I'm a bit behind.
Now that 6.0 is winding down I can hopefully catch up on some of it - and apologies to those of you with e-mails in that pile. At least you know it's not a personal insult!

Let's get to some Ruby screenshots. One thing I fixed this week was some bugs around the "Open Type" dialog (Ctrl-O, or Command-O on the Mac). I finally made "CamelCase" navigation work properly not just for classes but for module qualifiers as well, so if you for example want to open ActionController::Base, just type AC::B:

If you had typed AV instead it would have shown ActionView instead of ActionController, and so on.

Another thing I fixed is the ability to specify a specific method in a class - just use "#" as in rdoc to specify Class#method, or omit the class to search across all classes. Let's jump to methods starting with rend such as Rails' render:

Or how about the to_xml methods - but only in modules that start with "A":

You can also use wildcards. Here's all methods that contain load somewhere in the name:

P.S. There are still some bugs around being able to use camel case and regexps when filtering methods - I'll address those in the first update release.

Ruby Screenshot of the Week #22: Go To Specific Location

2007-10-26T10:16:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

It's bugfixing all the way these days - I apologize for being behind on my e-mail. We're freezing 6.0 pretty soon (in eight days), so I'd really like to get some help testing the last minute fixes. More about that shortly. But first, some screenshots.

One longstanding bug we've had is that our "Go To Declaration" (holding the Ctrl or Command key down while clicking on classes or methods) would jump to a different place than you were intending. With Ruby's open classes, there are many definitions for a class, so if you want to jump to say the File class, did you want the one in ftools.rb? Or perhaps in pp.rb? We have some heuristics which pick which reference is "best" - it involves looking at things like whether each declaration has documentation, whether it's directly loaded by your file using require statements, and so on. But this can never be perfect. So, to solve this problem, Go To Declaration clicks (or Ctrl/Command-B) will now pop up a dialog when there are multiple possibilities. As before, one item is NetBeans' best guess - and it's shown first and in bold. All you have to do is press Enter or click on it to jump as before. But other matches are shown too, in a sorted order. First are the documented entries, and at the very end, :nodoc: entries (shown with
a strikethrough font effect).

Here's how this look if you for example try to jump to TestCase:

If you don't like this behavior, you can always turn it off by running NetBeans with


-J-Dgsf.im_feeling_lucky=true

This was added just this week. Something related which has been there for a while is documentation
tooltips. If you're holding the hyperlink-modifier key (Ctrl/Command) and hover over methods and
classes, it will display a tooltip with the type of the symbol and its documentation. For example,
in a Rails controller test, here's what I got:

I just (a few hours ago) checked in a bunch of changes to clean up how NetBeans handles the gem load
path. It should now finally handle $GEM_HOME properly, as well as vendor gems and in particular, vendor/rails. Thus, the active record completion I showed last week
should now work with Rails 2 and edgerails. NetBeans should properly pick gems both from the current project as well as the current gem root (based on which gem version is higher). However, all of these changes were a bit involved... So I would really appreciate if people could grab the current bits (build 4866 or later from http://deadlock.netbeans.org/hudson/job/ruby/) and take it for a quick spin. Make sure that code completion etc. picks up your gems as before. You may have to wipe out the cached indices (userdir/var/cache/) if you have any problems. Don't worry, it's always safe to wipe out stuff inside var/cache.) If there any problems, please let me know now since we're about to freeze for 6.0.

P.S. Beta 2 was released this week - download,
New And Noteworthy

Ruby Screenshot of the Week #21: ActiveRecord Completion

2007-10-16T09:42:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

Let's jump to the good stuff right away:

Okay, now let's motivate it. Let's say you're writing a migration:

Hmm, what's the second parameter to the column method again?

Ah yes, the column type. Notice how the RDoc for the method call surrounding
the completion point is shown above - and perhaps more importantly, the symbol alternatives for
the current parameter are also
proposed below. Let's choose one.

Ah yes, the third parameter - the options. Again the documentation is
shown above (I've cropped it in this image) where you can read the details -
but many of the alternatives are listed here. Let's choose the :null hash key.

The parameter completion support I've shown here isn't specific to ActiveRecord. Let's say you're in
an ERB file and calling into say the NumberHelpers:

Anyway, we're done editing the migration. Now let's jump over to a controller file and reference the Product model that is using the database table for this migration. Let's ask for completion on the @product field that was just populated with a Product object:

The icon should make it really clear that these attributes are coming from the database as opposed to some dedicated attribute code in the Product implementation. Notice how NetBeans also shows the type for each of the columns. Completion also works for the dynamic finders that Rails generates. Let's ask for completion on find_by (this also works for find_all_by):

NetBeans offers code completion for models by examining the migration files. Let's go create another one. Here's
completion again, this time completing on the table name argument to rename_column:

Let's say we rename the description column to desc:

If we now invoke code completion in the controller again, notice how the Product attributes correctly
reflect the result of combining the migrations:

NetBeans will also use the schema.rb file that Rails will automatically generate if you run the db:schema:dump Rake target. This is useful if your migrations are doing creative things that NetBeans can't figure out, or if you're renaming tables (which NetBeans doesn't model right in this release.) With a schema dump file, not only does NetBeans have to do less work to figure out your migrations, its format is predictable such that the code completion should be completely accurate.

P.S. This doesn't work right if you freeze Rails into your project; you need to be using Rails via Rubygems. I'll fix that soonish.

Ruby Screenshot of the Week #20: Purdy Colors!

2007-10-08T07:05:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

A lot of people have asked for a "dark color theme" for NetBeans, possibly because there are several attractive dark color schemes for TextMate, a favorite editor among many Ruby developers. Jerrett Taylor has designed and contributed a great dark color theme for NetBeans, "Dark Pastels". I've wrapped it up as a plugin. As of today, it's prebundled with the continuous builds on http://deadlock.netbeans.org/hudson/job/ruby/, but for other versions such as beta1 and the upcoming beta2, you can download the plugin from here and install via Tools | Plugins (go to the Downloaded tab). It should hopefully also appear on the Auto Update center pretty soon.

To switch to this color theme after installing the plugin, open the options dialog, go to "Fonts and Colors" and choose the "Dark Pastels" color theme.

Let's get on to the screenshots! Here's a Ruby file:

...and here's an RHTML file:

Note that the plugin only replaces the editor colors. Other windows such as the navigator and project views keep the general look and feel of the whole application, so you can either slide these off to the side, or install a custom look and feel with colors more to your liking.

Here's what the plugin looks like in the Plugin Manager. As you can see I've named it "Extra Themes" such that it can hold several optional themes, so if you've got a color scheme to share, please do!

A huge thanks to Jerrett!

P.S. The theme the font to "Monaco", which is available on the Mac. If you're on a different platform you may want to go a tweak the default font to one that looks good on your system.

Disable Crashing...

2007-10-02T02:09:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

If you're on OSX, and you've experienced NetBeans 6.0 beta crashing on you, read on...

Right before beta1, we tweaked some of the Java VM startup flags NetBeans uses. In particular, we switched to the "Concurrent Mark Sweep" (CMS) garbage collector, which has a nice performance profile for IDE usage, since collection happens mostly in parallel so you don't get noticeable pauses.

Unfortunately, it turns out that these flags cause a lot of problems on OSX. In particular, they cause frequent virtual machine crashes!

Knowing this, for beta2 we've turned off those flags when running NetBeans on OSX. But that doesn't help you if you're trying to run beta1... Luckily, it's easy to fix it yourself, since the VM parameters are specified in a text configuration file.

First, open the netbeans.conf file. On my Mac, I installed NetBeans in Applications under NetBeans, so the file is


/Applications/NetBeans/NetBeans\ 6.0\ Beta\ 1.app/Contents/Resources/NetBeans/etc/netbeans.conf

The file contains this:


# Options used by NetBeans launcher by default, can be overridden by explicit
# command line switches:
netbeans_default_options="-J-client -J-Xms32m -J-XX:PermSize=32m -J-XX:MaxPermSize=200m
-J-Dapple.laf.useScreenMenuBar=true -J-XX:+UseConcMarkSweepGC -J-XX:+CMSClassUnloadingEnabled
-J-XX:+CMSPermGenSweepingEnabled"
# (Note that a default -Xmx is selected for you automatically.)

# For JVMs which does not support Concurrent Mark & Sweep garbage collection
# algorithm remove "-J-XX:+UseConcMarkSweepGC -J-XX:+CMSClassUnloadingEnabled
# -J-XX:+CMSPermGenSweepingEnabled" part of options
# (see http://wiki.netbeans.org/wiki/view/FaqGCPauses)

Remove the bold section above; in other words, remove these 3 flags:


-J-XX:+UseConcMarkSweepGC -J-XX:+CMSClassUnloadingEnabled -J-XX:+CMSPermGenSweepingEnabled

Now when you restart the IDE should behave better.

Ruby Screenshot of the Week #19: Comment Reformatting

2007-09-26T06:53:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

I've been working on beefing up the RHTML support this week, but since I'm not done yet I'll talk about that next week. Instead I'll show you a feature that's actually in beta1, but you may not be aware of.

Let's say you have this code:

Have you ever wondered what the vertical faint red line on the right hand side of the editor is? It's the soft text limit line. It's telling you that beyond this line, you're going over 80 characters. There's nothing magical about 80 - you can configure it to something else, as I have done here, but more on that later.

Anyway, this comment is obviously not pretty since I've pasted in some text with long lines. This happens to my comments all the time after I edit them, removing a sentence here or adding another there.
But let's get to the point. Place the caret somewhere in the comment (as I have done). Now press Ctrl-Shift-P (on OSX, Command-Shift-P). Voila - the paragraph gets reformatted:

Notice that the IDE understands RDoc conventions. It has left preformatted code alone, and has recognized the numbered list and has formatted it appropriately. (There's also a hidden mode you can enable such that it reflows the current paragraph automatically as you edit comments.)

You can configure the text limit line in the general editor options - it's called "right margin":

One other interesting thing you can do with comments is view how RDoc will format them. Just use the normal "show documentation" gesture (Ctrl-Shift-Space, or Command-Shift-Space, to show the documentation for the symbol under the caret). This normally shows the documentation for a class or method that your caret is pointing to, but inside a comment, this will show the comment itself rendered rdocily:

That can be handy to check your docs as you're editing them (although this wasn't working properly in beta1, so get a daily build). The above example doesn't contain a lot of interesting rdoc markup, but let's say you brought this up on for example the form_tag method, you'd see something like this:

Notice how some of the code fragments are syntax highlighted as well - this is taking advantage of the enhanced rdoc rendering I've described earlier. And when tweaking your documentation, don't forget spell checking!

Finally, the above comment screenshots are a bit boring. Inline use of rdoc tags are also syntax highlighted. We were just discussing the meanings of the various colors on
dev@ruby.netbeans.org, and the following screenshot shows the meanings of the various syntactic constructs. Notice how rdoc tokens like :nodoc: and words surrounded by underscores are highlighted:

Ruby Screenshot of the Week #18: Errors and Snippets

2007-09-20T06:50:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

Tim Bray just wrote about error messages and their occasional difficulty for users. I ran into the same issue myself a couple of weeks ago when somebody filed a bug that NetBeans didn't correctly handle Ruby documentation markers. When looking at the user's source, I realized the error was right in the user's source file - but the parser message hadn't been particularly helpful: Syntax error, unexpected =.

This of course seems like an area where the IDE can help. So, as of the latest builds, there are some error rule handlers (in the experimental hints plugin) to help with this. Suppose you try to add in a documentation block like this:

The lightbulb on top of the stop sign tells you there's an associated suggestion. Press Alt-Enter to see the error message and suggested fix:

Applying the fix will obviously correct the indentation of =begin and =end. Here's another example - opening a file with ambiguous parameters:

I would really like your ideas on other common error patterns I can detect and better yet, fix. (See
RubyFeedback or leave comments here.)

While we're on the topic of quick fixes, the experimental hints also include some new suggestions for converting between brace blocks and do/end blocks. If you place the caret within the first line of a do-block or a {}-block, a little lightbulb will appear in the left margin. If you press Alt-Enter, you'll see some applicable fixes:

The exact list of choices shown obviously depends on the block. If you do this from a do/end block, the conversion goes in the opposite direction. And if you're looking at a multi-line block rather than a single line block, it will offer to collapse the block into a single line rather than expanding it as shown here. (It only offers this if it can fit the statements on a single line within the right-hand side margin, as shown by the faint red line in the editor.)

Unsurprisingly, applying the first fix gives us this source code for the block:

(This operation will sometimes also insert parentheses around the previous argument list when necessary, since {}-blocks have different precedence than do-end blocks.)

Finally, I just fixed some bugs in the code template handling code. If you invoke code completion you should now see the possible code snippets that match your input - along with their tab trigger names on the right and the full code template in the documentation popup:

That's it for now. Don't forget that NetBeans 6.0 Beta 1 was just released. The
New And Noteworthy document has the rundown on the new features included since Milestone 10. (Most of the things I've described in this blog entry were checked in after the beta cut off but beta is more stable for regular use.)

P.S. Rails creator David Heinemeier Hansson had some nice things to say about Sun's Ruby and Rails efforts. There's no evil plan, I promise!

Hello World!

2007-09-07T09:34:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

The "Java Posse Hello World Tour 2007" is about to kick off :-) Carl, Dick and I are heading to Norway next week for JavaZone, where we'll do a live session as well as hopefully get some great interviews and just have fun. I'm also doing a talk on Ruby Tooling.

Joe can't make it - he works on the web store at Apple, and apparently they're busy selling stuff! We're also going to JavaPolis in Belgium in December. I'm not sure if I'll be able to go yet, but the other three guys are confirmed.

If any of you will be at JavaZone next week, please say hi!

Here's our world tour poster, courtesy of Oliver Widder:

New Demo Screencasts Available

2007-09-07T03:22:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

NetBeans.tv was recently launched. It's a community site where you can view, upload and rate videos related to NetBeans, such as demos and tutorials, interviews, and so on.

Cindy Church has recorded and edited together three demos where I show NetBeans and the Ruby support.

The JavaOne Demo (9 minutes). This is roughly the same outline I followed for the demo in James Gosling's keynote at JavaOne this year. It's a demo which shows both Java and Ruby editing capabilities as I create some JPA entity classes in Java, and then proceed to access these from a Rails application using JRuby.
- You can download a higher resolution version of the video here (120Mb).
- The demo script is available here.
Code completion (2 minutes). In this brief demo I show some simple code completion scenarios for Ruby. You can also download a higher resolution version (27 Mb) of the video. I was winging this demo (without a script) so I didn't spend much time on the various types of code completion, but take a look at this blog entry where I get into a bit more detail. Also note that the code completion documentation has some additional smarts to it above what rdoc gives you, described here.
Quick Fixes (3½ minutes). In this demo I show some of the quick fixes available for Ruby. Some additional hints were added after the demos were recorded - take a look at
this wiki page for an up to date list.
You can also download a higher resolution version (44 Mb) of the video.

Seeing myself on the video screen makes me super happy that Java Posse is an audio-only podcast!

A big thanks to Cindy Church and Mike Quillman who did all the hard work on these demos.

Ruby Screnshot of the Weeek #17: Spelll Checkinng

2007-08-26T08:26:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

One of my favorite plugins for NetBeans 5.5 was Jan Lahoda's spell checker.
It turns out Jan has updated it to work with NetBeans 6.0, so I wrote some bindings for it to work with Ruby as well.
Briefly, it highlights spelling errors in comments and documentation (=begin/=end) sections. This also works in
embedded Ruby code in RHTML files, and in RHTML files it also spell checks the text content. Ok, screenshots:

The above is the documentation for Rails' url_for method. As you can see there are a couple of typos.
If you place the caret on one of the words a lightbulb will appear in the left side gutter; press Alt-Enter
to see the possible fixes:

As you can see, you can very easily add known words that aren't in the default dictionary to your own private list.

Here's an RHTML/ERB file:

Since this is a file in one of my own projects, NetBeans offers to add this word to a project-specific dictionary. This wasn't available for the above Rails source file since it's in a library outside of my projects.

The Ruby spell checker currently skips words in comments that look like Ruby identifiers, such as
CamelCase words, method_name words, and :symbols. Single-character words are also skipped. Finally, it skips
rdoc preformatted text (indented comment content) since that typically contains code fragments which contain
lots of unrecognized words. It might be an interesting improvement to try to help with typos in actual
class and method names, such as a "Controler", but I've gotta figure out a way to avoid generating tons of false positives here (what's a Scanf? :-)

I've uploaded a version which should work with NetBeans 6.0 here. Unzip it, then go to the Tools | Plugin Manager, open the "Downloaded" tab and install the individual nbm files. (You may have to restart the IDE.) The zip includes an English dictionary. This is the dictionary from ispell (unzip the dictionary.nbm file and you'll see it). You can add other languages in the Options dialog; these should be ispell dictionaries. You can also change the text locale in the Options dialog; when I opened some files in the RSpec distribution it immediately complained about the British spelling "behaviour" instead of the American spelling, "behavior". I presume this would be fixed by switching from en_US to en_GB (both are included).

P.S. Somebody asked me for 6.0-compatible versions of the strip-whitespace and highlight-tabs modules; here
they
are.

P.S.2. The spell checker modules obviously work for Java too; if you've been looking for NetBeans 6.0 spell checking, grab the same .zip but skip installing the ruby-bindings .nbm file.

Back from vacation

2007-08-17T13:45:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

I just came back from a wonderful week in Hawaii, on the big island. The highlight was obviously our wedding. We had planned to get married on August 14th, on the beach at sunset, but because of Hurricane Flossie most beaches were scheduled to close. It didn't turn out to be a problem - we just got married a day earlier. It was a wonderful moment and we were thrilled to have our children there to be part of it. And obviously the rest of the vacation was great too - how can you go wrong with volcanoes (both the world's most active volcano, Kilauea, and the world's largest volano, Mauna Loa), waterfalls, snorkeling over coral reefs with turtles and tropical fish, and ....
piña coladas ?

It will take me a few days to get the sand out of my shoes, the tropical air out of my sun hat and get through my huge inbox. Apologies to those of you waiting for some sort of response from me!

Ruby Screenshot of the Week #15: More Hints and Quick Fixes!

2007-08-09T06:36:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

Ola Bini just posted a blog entry entitled "Ruby Is Hard". In the blog entry he shows a short code snippet which does not do what you might think upon reading it. This immediately reminded me of a dog-eared page in my worn-out copy of "Programming Ruby", specifically page 167, in the "But It Doesn't Work" section. The book covers the same problem and explains what the problem is and how to fix it.

I had marked the page for myself because when I first read it, I thought "that's something the IDE should be able to detect and warn you about!". So when I came across Ola's blog entry yesterday I figured I really should do something about it - and I had the perfect opportunity: A Java Posse recording session at Dick's new house last night. I've claimed before that writing quick fixes for Ruby in NetBeans is easy, and it really is - I completed this one as a background activity while having fun with the rest of the Posse. We are however past feature freeze for NetBeans 6, so when I'm adding fun features like this I put it into the "Experimental Hints" module, which is not part of NetBeans 6. It -is- however included in the continuous "Ruby IDE" builds you can get here - and you can also install it using the Plugin Manager in standard NetBeans.

So without further ado, here's what you get when you now open up Ola's example and the "Programming Ruby" example in NetBeans with the new hints:

As you can see, it's detecting the case there are local variable name assignments that match a writable attribute in the current class. If you hover over the warning it will tell you so:

If you hit Alt-Enter, you can see the possible fixes:

These should be pretty self-explanatory. At first you may go "Huh?" and jumping to the relevant attribute may help you figure it out. The second fix will simply change the assignment to the recommended form, and the third fix will let you rename the local variable to avoid any confusion.

In order to avoid any false positives I ran this hint over a large code base (all the Ruby libraries and Rails libraries) and it came up with a handful of warnings. These probably aren't bugs, but it's at least potentially confusing; here's baseData.rb from Ruby's SOAP library:

There are some other experimental hints too, in particular, a hint which detects actions in your controllers that don't have associated view files and offers to create them (using the Rails code generator), as well as various name warnings. Here's a warning which detects un-Ruby-like method names and local variable names (camelCase instead of not_camel_case) - this one from a Rails test case:

Here's the current customizer. Some of the hints are not enabled by default, so you should inspect these yourself and enable those you are interested in. One hint I definitely didn't want to enable by default is the "constant name" warning. I was under the impression that constants should use all upper-case letters separated by underscores, and this is indeed the case in lots and lots of Ruby code. But there are quite a few exceptions, where constants are just capitalized - so this seems like a warning that may need some tweaking or is an individual preference. Here's the customizer:

In other news, a lot of bug fixing is happening so stay up to date with the builds :)

Code Advice #15: Name getters properly!

2007-07-24T05:45:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

(See intro for a background and caveats on these coding advice blog entries.)

It's been a while since I've posted Java-coding opinions. But I couldn't resist on this one. The tip itself is straightforward:

A getter method's name should not sound like an action method.

Getter methods and setter methods should not have the same name.

I'm speaking from bitter experience since I just fixed a bug where my code had accidentally been calling a getter method, when I thought I was calling a setter method.
The method in question is java.lang.ProcessBuilder#redirectErrorStream. If you're launching a process, and you want to read its output, you may want to redirect its error output to its standard output such that you only have to read the input from a single source (assuming you don't care to distinguish between output and error.)

Well, my code was initializing the ProcessBuilder:


ProcessBuilder pb = new ProcessBuilder(args);
pb.directory(pwd);
pb.redirectErrorStream();

The problem here is that redirectErrorStream() does NOT redirect the error stream! It just returns false to tell me that it's not yet planning to redirect the error stream. The correct way to do this is


ProcessBuilder pb = new ProcessBuilder(args);
pb.directory(pwd);
pb.redirectErrorStream(true);

That's right - the setter and the getter are overloaded! Ewwwww!!!

This is the kind of thing a bug detection tool like findbugs could detect. It already warns if it sees you doing something similar, like calling String.trim() without storing the return value. Unfortunately, it didn't warn me about this case - so I filed a request. But this was a great reminder to run findbugs on my code again, which turned up some other interesting things to look at...

NetBeans Ruby support interview

2007-07-24T05:43:00.000-07:00

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

Roman and Gregg interviewed me in the latest episode of the NetBeans podcast.

Here are the shownotes from Roman's blog:

0:00 Introduction and Tor's podcasting, he's also a podcaster at the Javaposse

2:30 What Tor has worked on at Sun: Java Studio Creator,
Project Semplice,
and the Ruby
tools

5:00 Overview of Ruby features in the
NetBeans IDE

7:25 Debugging Ruby

9:50 Rails support

10:51 Switching between Ruby implementations

11:49 Implementation of the type inference and code completion logic

17:10 Implementation of refactoring features

18:54 Features Tor wants to implement next

21:33 Community feedback

23:17 Why should Java developers look at Ruby?

26:38 Other Ruby development tools

29:49 A version of NetBeans IDE that just has Ruby support?
Check out this page on deadlock

32:16 Opportunities for contributors and cool features; check out the
wiki page.

34:55 Support for other dynamic languages.
Erlang IDE based
on Tor's code.

The episode is here, subscription is here.

Tor Norbye's Blog

Building the Android IDE Tools

Android

Next Chapter

System.exit(0)

New blog home

Don't Use Implicit Return Types

NetBeans 6.9 Released

LCD Subpixel Rendering

Bay Area JUG Roundup 2010

Pixel Considerations

nbgit for NetBeans 6.9 beta

IDE tip: Go To Implementation

IDE tip: Create Build and Execution Shortcuts

How to Write a Memory Leak Unit Test

IDE tip: AST-based Selection

IDE tips

Transparent windows on Linux

300 Episodes

Java Posse Roundup

Using Mercurial over ssh without typing the password

How to Render a JavaFX Node into an Image

My Test Environment

How to determine the JUnit 4 current test name

JavaFX Coding Conventions

NetBeans 6.7.1 is out - with JavaFX 1.2 support

Back from Vacation

New iPhone software - now with podcast speedup

Code Advice #16: Don't Encode Symbol Type in Variable Names!

Format All

The Authoring Tool

Run Tests - Without Focus Loss!

...at least my house didn't burn down!

JavaFX editing tips!

Nice touch, Skype!

Catchup

Add Effects to the right Container!

JavaFX Text Component

NetBeans Screenshot of the Week 42: JavaScript Native Interface

Java Posse Roundup 2009

New Job

NetBeans Screenshot of the Week #41: Type Assertions

NetBeans Screenshot of the Week #40: Python Test Runner UI

Ruby Code Coverage in the builds now

Happy New Year!

VirtualBox Rocks!

JavaOne Submissions Due

NetBeans Screenshot of the Week #39: Ruby Code Coverage, Python Code Coverage

NetBeans Screenshot of the Week #38: E4X Support

NetBeans Screenshot of the Week #37: JavaScript 1.7 Support

NetBeans Screenshot of the Week #36: Python Code Completion

NetBeans Screenshot of the Week #35: Support for Python's __all__ Variable

Ruby Screenshot of the Week #34: Detecting Duplicates Hash Keys

NetBeans Screenshot of the Week #33: Finding Unresolved Symbols

NetBeans Screenshot of the Week #32: Python Import Management

Champagne!

Mercurial Tip: Checking in regularly with uncommitted changes in your clone

The Solution

Find Memory Leaks!

Screenshot of the Week #31: Python, Groovy

Multilingual NetBeans: PHP, Python, Scala

Ruby Screenshot of the Week #30: New YAML Editor

Ruby Screenshot of the Week #29: Test Navigator for RSpec

Ruby Screenshot of the Week #28: Unit Testing, and Color Themes

New Unit Test Runner!

The Aloha Color Theme

JavaOne 2008

JavaScript Type Inference in NetBeans

Screenshot of the Week #28: NetBeans + JavaScript = True!

Feature Comparisons

Roundup Roundup

Why Your JavaOne Submission Was Rejected

Ruby Screenshot of the Week #27: Task List

Ruby Screenshot of the Week #26: Ruby 1.9 Changes - hashes and case statements

Ruby Screenshot of the Week #25: require_gem

Ruby Screenshot of the Week #24: Quick Fix Previews

Quick Hi

Ruby Screenshot of the Week #23: Extract Method and More Refactorings!

Ruby Screenshot of the Week #23: Open Type and Open Method

Ruby Screenshot of the Week #22: Go To Specific Location

NetBeans Screenshot of the Week #35: Support for Python's all Variable