Tuesday April 29, 2008

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!

Friday April 04, 2008

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!

Thursday March 13, 2008

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!

Monday December 03, 2007

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.

Monday November 12, 2007

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.

Monday November 05, 2007

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.

Monday December 11, 2006

There have been several great releases lately, and I'm remiss in covering them. However, they've been covered in great detail elsewhere. First, NetBeans Visual Web Pack shipped on schedule, bringing Creator functionality to NetBeans, along with new support for Java EE 5. Second, Mustan... ^H^H^H^H Java SE 6 shipped today. It's a great release. The number one reason I install it whenever I get to a new system is that I need the improved font aliasing built into Java2D - and of course, the gray-rect-fix. However, there's another reason I crave the release even when I'm on OSX: @Override. Yes, @Override has been there since Java SE 5, but in Mus... Java SE 6, you can use it to indicate that a method should implement an interface method, not only a method inherited from a super class. (Which arguably @Override should have meant all along.) Now if only Apple could ship an update to its dated September pre-release...

Anyway, I have an excuse for being late to blog. In addition to some work on JSR 273 which is coming along nicely, I've been coding away to get more Ruby tools support for NetBeans. Charles and Tom will be demoing JRuby 0.9.2 (which just shipped, congratulations!) at JavaPolis this week, and showing the NetBeans tooling in the process.

I thought I would share another screenshot with you at this point. This shows the new language embedding. Notice how there's Ruby inside string literals, rdoc tags inside comments, string escape codes highlighted specially, and so on.

This is all made possible by the new Lexer API in NetBeans. It's really nice to build on top of it; writing incremental lexers is a snap. This is part of NetBeans 6. If you've been using recent milestones, you might have noticed that all our javadoc is highlighted in your Java files. This is not done through hacks in the Java lexer - it's done through embedded sections where the Java comment tokens are then sub-tokenized by a Javadoc lexer. It's not just done for javadoc - if you look at your String literals you'll notice the same String-sequence highlighting that I'm showing for Ruby above. It only changes the font to bold, so it's a bit subtle. Perhaps something we should tweak before the release.

In Charles' pre-review of the Ruby support, he wrote some very nice things about me ("Tor Norbye is a programming machine", etc.) Thanks Charles! While it's nice to get all the credit, I really want to point out that this is all made possible because of the tremendous work on the editing infrastructure for NetBeans 6, by a number of great NetBeans engineers. Not just the Lexer, which I've described above, but all the other things I've relied on, such as the infrastructure for semantic highlighting, asynchronous parser task scheduling, and so on. I would love to give individual credit here, but I'm not sure exactly who to attribute all the work to, so I'd rather credit all of you rather than snub anybody. Not to mention the fact that I have an excellent Ruby AST to work with, thanks to JRuby!

Several of you asked after my last screenshot where or when you can download the code for this. It will show up in NetBeans soon, but since the work started in closed source, I have to follow the established open-sourcing process. It's in progress, but I can't make specific predictions about when it will be done. (2006-12-11 20:50:56.0) Permalink Comments [3]

Wednesday November 29, 2006

Click on image for full size. Some things to notice: semantic highlighting (for example, parameters are shown in different colors than local variables), code completion, mark occurrences (other uses of the length method under the caret is highlighted), ...

You'll see more at JavaPolis... and on this blog!

Tuesday September 26, 2006

(Parts 1, 2, 3, and 4.)

The Build Monitor plugin for NetBeans allows you to see the status of continuous builds, right from within the IDE. The Build Monitor works with several continuous build systems - CruiseControl, Hudson, and of course the NetBeans continous build. You can monitor multiple build sources - all you do is name your build and point to an RSS feed where the plugin can fetch the build status. Each build is then displayed right in the IDE status bar. You can set the polling frequency yourself; I've set mine to check every minute! Here's what this looks like:

You can grab the Build Monitor plugin from the Beta Update Center, or from nbextras.org.

Yesterday, I set up a continuous build for the project I'm working on. It was really simple. All I had to do was download glassfish, run its setup script, download Hudson, and drop the hudson.war file into the autodeploy directory in Glassfish. Then I just went to localhost:8080/hudson and from there I could set up a build using a simple web interface. I just needed to point to my CVS server (Subversion is supported too) and my ant scripts, and voila - continuous builds. If you want to take a look at what Hudson looks like in action, visit this page where you can see Glassfish itself being built in a Hudson setup.

Tips:

1. It's a bit tricky to configure the build monitor. The trick is to open the options, then go to the Advanced Options, locate the Build Monitor item, right click on it, choose new build monitor. Then set the RSS feed to the build failure (or all builds) feed you want to use - Hudson displays it right in the status page.
2. I had to restart the IDE before the build monitors showed up in the Status Line. We should set the needs-restart property of the auto update bundle.
3. I had problems using the most recent snapshot of Hudson so I grabbed a slightly older version and things were fine.

Thanks to Tom Ball and Jesse Glick for this plugin.

Friday April 28, 2006

I went to the Update Center and went checking for new features. On the nbextras site I found a new feature I instantly fell in love with.

This is a spell checker which lets you register dictionaries (the English ispell one is bundled), and then your javadoc comments are checked for spelling errors while you're editing, much like the java code is checked for parse errors. Any errors found are underlined - and there's even a quick tip which lets you instantly (Alt-Enter) replace the word with similar words in the dictionary.

After installing this, I opened a couple of files from the JSR 273 project (under development), and it instantly pointed me to several typos I then fixed! Here's one of them:

The plugin is also smart enough to not report typos for names following an @author tag, and so on. And the options panel lets you register additional dictionaries. It's easy to find many free ones for ispell on the web.

Very nice! Thanks Jan Lahoda. Now where's your blog? Actually never mind, don't let anything distract you from writing plugins in your spare time...

Monday April 24, 2006

A while ago I argued that you should completely avoid Tab characters in your Java source files. Use spaces for indentation. I won't repeat those arguments here. But even those arguing in favor of tab-indented source files agree that mixing spaces and tabs is evil.

The problem is that sometimes you're not aware that you're working on source with mixed tabs and spaces. This can happen easily if you edit the source files with an editor that has the wrong (as far as you're concerned) handling of Tabs.

To help avoid this you can use a simple NetBeans module I just committed into CVS, under contrib/fixtabs. You can grab the NBM file here and install via Tools | Update Center. I'll submit it to nbextras.org soon so you can get it there later.

Here's what the module looks like in action. If you for example open the JDK JTable class and look at the constructor, you'll see something like this (click for full size):

Ewwww!

When you encounter files like this, you can go to the edit menu and select the action to convert the tabs to spaces. You can also turn off Tab highlighting here.

(Update 4/28/06: I changed this such that the "checkbox" toggle is now in the View menu, along with other view states you can enable and disable, and I moved the Convert action to the Source menu along with other source transformation actions.)

The module is similar to one of my favorite modules (which I guess I haven't described yet) - the "stripwhitespace" module. That module highlights trailing whitespace in the current source file, and lets you remove these. Not only is the fixtabs module similar - it's heavily based on the same source code.

Let me know if you encounter any bugs.

Wednesday April 12, 2006

Don't get me wrong: I generally love the OSX user interface. But the one thing I can't stand is the file chooser. On other platforms, you can usually type the path you want to go to, but on the Mac, you have to drill down, with a mouse*, from one of the "root" directories - e.g. home, Desktop or Documents. Yuck.

If you're a keyboard guy like me, there is a solution: The Quick File Chooser. This plugin registers an alternate file chooser with the IDE, which is then used everywhere a filechooser is used.

The plugin is named the "Quick" file chooser for a good reason. Not only can I type in a path to a place I want to go more quickly than I can drill down to it with a file chooser (especially in directories with lots of files, such that I have to scroll to find the next intermediate folder to click on). But it also has additional shortcuts.

First, I can press the Tab key to force automatic completion. This works the same way as in modern Unix command line shells. If I've typed "P", and the only file in this directory that begins with a "P" is named "Projects", pressing Tab will update the path to "Projects". When there are multiple matches it will expand as far as possible.

Second, I can use environment variables again! Yipee!! I've really missed this feature. I used to do all my navigation with environment variables when I was an avid Emacs user. I had defined important directory locations with environment variables. For example, $D would point to the main debugger source directory; $E the editor, and so on. I could simply hit C-x C-f to open a file, and enter the path as $D/Breakpoint.cc to open the Breakpoint class. With the Quick File Chooser, you can again embed environment variables within the path, and everything is substituted correctly.

Here's a screenshot of the plugin in action. As you can see I've typed in an environment variable to jump to my NetBeans source tree, and I've started typing a path - and all the files are filtered down to the possible matches so far:

Thank you, Jesse and Tim!

If you want to get this module, go get it from nbextras.org/. The instructions for how to connect to it via the NetBeans Update Center are here.

*: There is an unintuitive way to jump to an arbitrary directory, in some applications, by going to the Search field and starting to type a path. Provided the first character is "/", this will cause a dialog to pop up where you can type the directory. But this is not a decent workaround, because it only works for absolute paths, there's no tab completion etc. And worse yet, many applications (including NetBeans) don't include a Search button next to the directory dropdown.

Friday March 24, 2006

Earlier this week, somebody got a picture of SWT creator Steve Northover "embracing" NetBeans. This promply made it into the Eclipse splash screen for nightly builds (along with a bugreport...). Here's the splash screen:

Via Roman I just learned that the NetBeans nightly build also has an "unusual" splash screen. Sure enough:

RCS file: /cvs/ide/branding/core/startup/src/org/netbeans/core/startup/splash_nb.gif,v
Working file: ./ide/branding/core/startup/src/org/netbeans/core/startup/splash_nb.gif
head: 1.5
branch:
locks: strict 
access list:
keyword substitution: b
total revisions: 15;    selected revisions: 15
description: 
----------------------------
revision 1.5
date: 2006/03/23 23:37:22;  author: tboudreau;  state: Exp;  lines: +531 -379
A fitting response to
https://bugs.eclipse.org/bugs/show_bug.cgi?id=132773
to be rolled back after the next nightly build :-)

If my eyes don't deceive me, the person on the right is the same Steve Northover, this time playing guitar with NetBeans developer and evangelist Tim Boudreau.

Things are getting very friendly between the two camps. Tim Cramer, head of tools at Sun, appeared at Eclipsecon this week and spoke on the Matisse integration into MyEclipse.

Competition is good for Java developers - and friendly competition is in my opinion even better.

Monday March 13, 2006

Jackpot is finally available.... well, as an alpha that is. But hey, I love to live on the bleeding edge - I always run with the latest and greatest bits I can get my hands on.

Here's the announcement, sent only to the NetBeans development mailing list. At this stage, the UI is not ready, but developers can start playing with the concepts and start writing refactoring scripts. Refactoring scripts, what's that you say?

Jackpot really is a new approach to refactoring. Sure, there are builtin refactorings - code transformations that are coded as direct AST manipulation. However, Jackpot also lets you write your own Rule files, using a special but obvious rule language. Rather than describe it here, just go check out the tutorial.

Unfortunately, there are no screenshots in the tutorial. And for any new software, the first thing I look for are screenshots. So, below follows a few screenshots to hopefully whet your appetite. It's exciting to see so many new innovations going into the NetBeans IDE!

Here's the first thing I did. I applied the "Add Override Annotations" transform. This goes and looks for all methods that are currently overriding another, and adds the new JDK 5 @Override annotation to all these methods. I've recently started using this annotation in my code, but I've added them haphazardly, so it's nice to be able to do this in one shot. When you run the transformer, you get a results window with diffs before you apply the change:

As I mentioned, you can write your own rule files too. This is the real big deal about Jackpot. It allows you to write your own, simple source substitutions - with full accuracy on types. The below shows some code cleanup rules. There are many many other rule files too, and more deprecated uses ones should be written.

Here's the current queries menu - queries simply list results, but doesn't actually change the code:

Here's the current transforms menu:

Note that it's very easy to add to these menus. Create your own rule files, open up the Command Manager and add a reference to your rule file (what, did you think "Tor's Test Rules" at the end of the menu above was part of the Jackpot distribution?). It then shows up in the menu and you can run it. Developers can then share these rule files. If you come up with some good rules, PLEASE please share them!

P.S. Remember it's an alpha so don't start complaining if you get exceptions, if the UI isn't Right(tm), etc.

Sunday January 29, 2006

Sandip "Plugin" Chitale has published yet another NetBeans module. This one adds a toggle button to the toolbar, which when enabled, causes occurrences to be highlighted in the editor. For example, if you put the caret on a field, all uses of that field in the file are highlighted. As another example, if you place the caret on a method declaration, then all exit points from that method (return statements, throw statements) are highlighted. And so on and so forth. Read the full description with screenshots and take it for a spin. Works like a charm with NetBeans 5.0 RC2.

Here's a sample screenshot from his blog showing what happens if you put the caret on a formal parameter in a method declaration (unfortunately the blinking caret didn't show up in the screenshot but imagine that it's on the highlighted parameter):