Tim Boudreau's Blog

September 2005 Archives

Follow-mode for NetBeans?

Is that a thing anybody wants?

I've written some (admittedly crude) patches that do the very basics; doing it right would be considerably more work (lots of little things like making sure you can't have two selections, eliminating duplicated decorations, etc.).

Somebody asked for a screen shot of the usages tree view - that's it on the left (sorry about the resolution, I haven't got anything decent for picture editing for windows on my laptop).

And another new NetBeans plug-in...

Having the flu gave me plenty of time to code this weekend...so, here is a module that does that.

There are some bells and whistles still to be added - like using wildcard imports if the number of imports from a single package exceeds some threshold number. But still, right now it should do what a lot of people have been asking for:

• Sort imports
• Break up groups of imports with newlines
• Replace FQNs in source with simple class names and add imports for them
• Replace wildcard import statements with explicit imports of all classes that are actually used

Probably eventually this functionality should be merged with Fix Imports in NetBeans, but I figured I could make some people happy by writing a small module that does that now.

Sate yourself with pleasure...read the NetBeans developer FAQ...

As I mentioned above, I've been feverishly growing the NetBeans Developer FAQ for plugin authors - have a look, edit, delete, whack away - it's a Wiki.

In the meantime, I can thank Judith Lillienfeld for finding these wonderful cashews with even more wonderful packaging in the supermarket here:

I'm not sure which I love more, the slogan

or the ominous yet pleasing sounding warning

Everybody, be on the lookout for the tasty. Alas, I'll be sauntering back to California soon.

Patterns, Schmatterns

I've heard decidedly kooky things about patterns (usually from people who don't code for a living). Typically it's the same type of hype that says that one day, in the land of milk and honey, all software will be made by "component assemblers" (who presumably get paid minimum wage). I'd like to coin a term for these thingies - YAWMTI - Yet Another Way to Make Talent Irrelevant. Yawn. Hasn't happened yet. (Hmm, YAWMTI doesn't really roll off the tongue does it? Maybe I should stick to my day job...).

When the gang of four book first came out, someone in a job interview suggested I buy a copy and read it. I did. It was disappointing. I just felt like, isn't this kid stuff?

There's nothing wrong with formalizing the obvious and the mundane. But it's really worth remembering that that's all design patterns do. There are no panaceas or silver bullets lurking within design patterns. It's a "pattern language" - a way of talking about doing, not a way of doing.

It's true that people create abstractions, and then build new abstractions out of those abstractions. Programmers are often (perhaps too often?) in the abstraction business. Coming up with a formal name for one or another abstraction is fine - it can indeed end up being a useful communication tool. But sometimes people forget that that's all a pattern is. Code is real, abstractions aren't - a pattern is a very lossy-compressed version of things you code every day. You can sleep in a house. You can't sleep in a blueprint for a house (well, maybe if you're very, very small...).

I expect there is quite a bit of value to patterns as a teaching tool - they could be a great way to teach people new to programming ways of thinking about what code does. Such mental tools are otherwise acquired through experience, reading code and ad-hoc "Aha!" moments, if at all.

Where the real value of design patterns ought to be is as a way to describe, to a machine, code that it should generate; and more interestingly for reverse engineering - identifying patterns in existing code, and using that information to visualize or describe what the code does to someone unfamiliar with it. Now that would be a useful application.

But trying to shoehorn all of my thinking into a canned set of predefined patterns? That's just silly.

Usages tree view for NetBeans

So last night I wrote it, and you can download it here. AFAIK it's solid, but I wrote it from start to finish less than 10 hours ago, so a wart or two is possible.

It's testimony to NetBeans APIs that it took me about 3 hours to write (most of that time testing things), and the entire module is a single .java file plus some icon image files.

The source is in contrib/javaUsagesNavigator on netbeans.org, and of course, covered by the open source Sun Public License as is the binary.

It's probably a testament to the power of the internet that I can do this from a hotel in Beijing while I'm on a business trip :-)

More Navigator fixes, the road from St. Petersburg to Beijing

Nevsky Prospect in St. Petersburg at sunset

Saturday, my friend Martin Ryzl, the original author of, and current manager of the development team for the NetBeans Mobility Pack and I flew from St. Petersburg to Beijing. It was the first trip for both of us to both cities. Particularly interesting was when the plane did a 180 degree turn in the middle of the runway (there are three sets of wheels, two under the wings and one in the middle - reverse the directions of the wing sets and pivot) - it was a disconcerting moment when we suddenly seemed to be executing an impossibly tight turn on the runway for our stop in Novosibirsk.

For the Novosibirsk to Beijing leg, I bug-fixed and growled and cursed at my laptop, while Martin glowingly showed me one after another another cool thing his guys had implemented in Mobility, that he hadn't had a chance to try before, but could include in his demo - for example, a stack trace from KVM only gives you a bytecode offset; NetBeans will now reverse engineer a real stack trace for you by reading the class file. You can now edit guarded blocks in the editor. Mobility just keeps getting cooler.

Martin Ryzl in the cavernous hall of Sun's temporary digs in St. Petersburg

The plane flight was productive. In a recent blog I listed some interesting line switches that affect the behavior of the Navigator component in NetBeans. A couple people pointed out that some of them were no longer working in NetBeans 5.0. Plane flights are a great time to get things working, so now they all are. A quick recap (with some new ones):

• nb.navigator.singleclick - one click to navigate between methods instead of double clicking
• navigator.string.abbrevs - strategically omit characters from method names to keep from needing a horizontal scrollbar (far from perfect, but handy)
• nb.navigator.relatedItems - highlight all callers of the selected method/field (currently infrequent false positives, working on it)
• nb.navigator.decorate - show overriding method names in bold, final stuff in italic. The performance problems with this feature seem to be much better in 5.0 trunk builds - might even be viable to turn on by default - we'll see
• nb.navigator.noscroll - Having Navigator scroll when the caret moves can be distracting; this disables auto scrolling. Works best if you dock Navigator to the right of the editor so it has a lot of height - for most java files, all methods will be displayed, and horizontal real estate is less critical than vertical screen real estate.
• nb.navigator.reordering - Allow (in natural sort mode only - right click and choose it from the menu) you to drag and drop methods to reorder them in your sources

./netbeans -J-Dsome.line.switch=true

People who know me know I have a perverse love of non sequiturs and mistranslations - even to the point of writing software that generates its very own non-sequiturs (almost a decade ago, but it still works...as well as it ever did). While my all time favorites come from an English menu in Warsaw, fascinating sayings in English abound. The following can hardly be called a mistranslation - this ATM machine is perfectly succinct and to-the-point:

Led Zeppelin meets ATM - who knew?

The food here has been fascinating and wonderful - particularly something called "Chrysanthemum water with honey" was wonderfully refreshing after a dehydrating international flight.

I have no idea what these folks do, but it sounds interesting:

So far so good.

"Split Class" refactoring?

I'll take a concrete case: When I was developing the new Output Window for NetBeans, I had a class that represented an output buffer, with methods for reading/writing data, getting offsets and line counts, etc.

Then I implemented line-wrapping. To make that fast, I started keeping some data about how many on-screen lines a "line" of data mapped to. The class progressively grew more hair as the wrapping code got more and more heavily optimized. At the end I had FrankenBuffer, with its buffer-related lines, and a whole bunch of methods relating to line wrapping (sometime I'll have to write a blog about how to do obscenely scalable line wrapping code - there are some neat optimizations you can do if you know the buffer only grows at the end, etc. Lots of fun with primitive int arrays and binary searches. Suffice it to say, yes, I did want the line wrapping code very close to the buffer code).

So what I needed was to factor all of the buffer stuff into another class, and delegate where needed. I even shopped the competition and checked out other IDEs, but didn't find anything that was really what I was looking for - you can do it in a hackish sort of way by first generating a superclass, then replacing inheritance with delegation, but it's somewhat painful.

Anyway, have other people been in this position? I have a feeling a "Split Class" refactoring would be pretty useful - but it could also be an artifact of the way I code - maybe the rest of the world wouldn't find it all that useful. Let me know.

Now, what would be really slick is if such a refactoring actually detected if there were certain sets of methods that did/did not touch certain member variables and made a good guess of one or more optimal ways to split the class without breaking anything.

Zdravstvujte NetBeans 5.0 (yes, 5.0)

The next release of NetBeans will be called 5.0, not 4.2.

What's in a version number? Well a lot of things. There was a lot of debate on the mailing lists about what should be the upcoming version number, and it's clear that there are many different schools of thought on when you increment version numbers. In the end, we took the bull by the horns. It's 5.0.

Some of the big changes driving the decision are Matisse, the new GUI builder, brand new, rewritten CVS support, support for Struts and JSF, deployment to many more app servers, and the really nice new support for building RCP apps on the NetBeans platform. As some of you know, we had pretty good support for building plug-ins through NetBeans 3.6; the same guy who maintained the apisupport module was the lead on 4.0 projects - so something had to give, and apisupport was what did.

In NetBeans 5.0, apisupport is back in a big way. Some of the highlights:

• Create a new plug-in from a template (hmm, gee, that's not that exciting...)
• Create a "suite" of plug-ins that make up your application
• Build/run/debug your NetBeans-based application within the IDE
• Hot-redeploy your plugins into a running copy of your application
• Debug "fix and continue" (hotswap) with your plug-ins
• GUI for configuring menus, toolbars and more in your NetBeans-based application
• Create the branding for your application (replace the splash screen, application name, hide/move/rename/etc. menu items, toolbars, main window contents, etc.) via a wizard
• Build a distribution of your application painlessly
• Templates and wizards for creating common NetBeans classes and components

So this is big stuff - it deserves a bigger version number :-)

I'm really looking forward to the Russia trip - I studied Russian at MIIS in college, but have never been to Russia. However my Russian is terribly rusty - five years of speaking Czech (which is close if you're not a native slavic language speaker, and doesn't seem nearly so close if you are one) has not helped. Today I speak Russian words with Czech grammar, or Czech words with Russian grammar. So we'll see if I can say anything coherent.

After that it's on to Beijing. Alas, I speak no asian languages.

This work is licensed under a Creative Commons License.