Monday Mar 16, 2009

NetBeans Screenshot of the Week 42: JavaScript Native Interface


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.

Friday Nov 28, 2008

NetBeans Screenshot of the Week #38: E4X Support


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

NetBeans Screenshot of the Week #37: JavaScript 1.7 Support


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.

Tuesday Apr 29, 2008

JavaScript Type Inference in NetBeans


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 Apr 04, 2008

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


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!

About

Tor Norbye

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today