GWT’s Hidden Strengths

I’ve been working on a particularly complex web interface recently, and have ended up writing tags to check the browsers so that layout and CSS can be different for certain browsers (not just IE, but Firefox as well). It’s plain old JSP’s and Servlets, and it’s a serious headache thanks to the complexity of the page layout. Theres even JavaScript the assists in the layout of each page.

Every-one by now knows that GWT buys you great cross-browser JavaScript (by writing different JavaScript for different browsers). What most people don’t know is that GWT also buys you is a moderately consistent look-and-feel across browsers. If you want to use weird and wonderful CSS, thats your affair, but in terms of the widget layout, it’s very consistent (assuming you don’t use CSS to layout your widgets).

I specifically exclude the use of CSS, since CSS behavior is so different between the different browsers that you almost want a Servlet to serve up different CSS for each browser (something very easily achieved by using the “User-Agent” header).

GWT’s other big strength is the time to market effect. It’s amazing how little code you need to write to get something working out of the door. So: first write in GWT, launch, then back port for older browsers and such.

Ways to abuse your ClassLoader

ClassLoading in Java can be a tricky business. For those who are not really familiar with writing a ClassLoader, here are some of the basics (before we start getting into the abuse):

1. Custom ClassLoaders should always override the “find*” methods
   1. This means you will conform to the standard ClassLoader policies
2. A ClassLoader first checks the classes it’s already loaded to avoid re-loading an already linked in class
3. A ClassLoader then checks with it’s parent ClassLoader to see if it can load the requested class
   1. This avoids people overloading the java.* packages
4. If all that failed, the ClassLoader attempts “findClass” which then calls “defineClass”

So you see, theres an order that things are done in to make things work smoothly. However, there are ways to abuse this system. Writing custom ClassLoaders requires certain permissions, so it’s assumed that you’re trusted when you write ClassLoaders.

Overriding java.* classes

First off, you can change the loading order and override java.* classes for other loaded classes. ClassLoaders can only effect what Classes they (and their child ClassLoaders) load see. This is a simple trick, simply overload all the “loadClass” methods and change it to simply “findClass”.

Injecting Classes

You could expose “defineClass” publicly, but that would be very dangerous, since any classes loaded by you automatically have a reference to your ClassLoader. So it’s a better idea to encapsulate the injection logic into the ClassLoader itself. For example:

public class InjectingClassLoader extends ClassLoader {
public InjectingClassLoader(Set<String> classFiles) {
for(String s : classFiles) {
injectClass(s);
}
}

private void injectClass(String name) {
InputStream in = InjectingClassLoader.class.getResourceAsStream(name);
byte[] buffer = ...;

// read the bytecode from the stream into the buffer

String className = ...; // transform the filename into a class name
defineClass(className, buffer, 0, buffer.length);
}
}

Class injection is a very useful trick if you’re generating byte codes on the fly. It breaks the lazy-loading in Java, since you’re forcing the classes to be loaded before they are actually needed. However, this in it’s own right could be useful for a gaming environment, where even class-loading may appear to hinder performance.

First impressions of Netbeans 6

I know I’m very late with this post, but I just haven’t really had the time recently to try out Netbeans 6. Now that I’ve spent a few days with it, I have a few things to say about it:

1. Memory Usage

Wow! How? Netbeans 6 is operating inside the 30 – 40 Mb range instead of the 90 – 200 Mb range. I have no idea whats happened under the hood, since Netbeans 6 seems to be doing a lot more “intelligent” work than Netbeans 5.5 did, and that usually translates to more memory being used.

2. Code Completion

Okay… This is one of the big features in Netbeans 6, but what nobody seems to be saying is that is extends well beyond the range of the auto-completion drop-down. Netbeans 6 automatically suggests names, what arguments you’re likely to use, etc. For example:

List<Person> people;

public void addPerson(Person p) {
people.add(p);
}

In the above example, the instant you open brackets for “people.add(“, Netbeans fills in “p);” and selects the “p”. This works not just with collections, but any method you care to name. It’s very impressive, because it chooses the parameters intelligently, based on the data-type.

And did I mention that the code-completion is about a million times faster than it used to be?!

3. Code Formatting

Finally, Netbeans gets decent code formatting. The new code formatting can conform to some of the most obscure styles I’ve ever seen, and the configuration is clean and easy to work with.

4. Surround With

The surround with functionality doesn’t sound like anything spectacular, until you see it work with a really tricky piece of code, and it does something unexpected… but amazingly elegant, like simply add another “catch” onto the end of and existing “try” block instead of writing a whole new “try/catch” in.

Like is mentioned on the site, Surround With is not just about “try/catch” anymore, it does any type of block you care to name, and like everything else in NB 6, it does it intelligently and elegantly.

Summary

Netbeans 6 still has a few niggly bugs (in beta 1 at least), but for me, none of them are show-stoppers. For my income producing work, I’m likely to wait until it’s released, but if you haven’t already downloaded it and tried it out, I strongly suggest you do. You may just fall in love.