Oracle Blog

Tor Norbye's Weblog

Thursday Jun 17, 2010

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

Thursday May 20, 2010

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!

Wednesday Apr 28, 2010

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.

Thursday Mar 25, 2010

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

Tuesday Jul 28, 2009

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?

Wednesday Apr 29, 2009

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 theroundup 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!

Monday Mar 16, 2009

At the Roundup last week I talked toRobert 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.

Tuesday Jan 13, 2009

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:

Monday Jan 05, 2009

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.

Friday Jan 02, 2009

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

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:

Friday Nov 28, 2008

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:

Tuesday Nov 25, 2008

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.

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

Thursday Nov 13, 2008

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: