It's really quite clever. The browser is basically a big sandbox for translated java, and the toolkit acts as a gateway to all the browser-based things you need to do, like manipulate CSS definitions and shove DOM objects here and there, changing the layout of the page. Under the hood it's messy and ugly, however. If the cross-compiler is doing something you don't expect, or if it just can't do something you want, you have serious problems.
It's possible to work with Adobe's SVG (scalable vector graphics) in this toolkit, and do neat things (the GLAMM project is a fine example) but if you want to do stuff with Adobe's Flash, you may as well douse yourself in gasoline and dive into a campfire. Less painful.
The "final" indicator in Java is used to declare that once a variable has been defined with a value, that variable cannot be changed to another value for the life/scope of the variable. You can declare a variable as "final" without actually assigning it anything, which means you can then assign it one of several values based on logic later on, but once it gets any value, that value is fixed. The compiler will kick you in the head if it discovers you are violating this rule, because it does a few handy optimizations based on it. It's like "const" in C but it can be applied to more things.
Is it possible to create and code a class that handles an object of "unknown" type, and then declare what that type is when you instantiate that class. For example you could write a "list" or "tree" class that puts objects of some unknown (but consistent) type at each node in the list or tree, and then indicate that the type will be "integers" when you instantiate the class in your code. Java will then make sure that whenever you are passing an object into that class to be stored in the tree, it will be of the correct type ... or it will barf on your head and put you in the pillory and tell other developers to throw vegetables at you.
The documentation for various parts of the Google Web Tools appears to be written by people who do not know the difference between documentation and a wiki. Most pages appear to be a dumping ground for whatever the author personally had difficulty with when they were attempting to use their own toolkit, or explain it to someone else. For example: "The methods are then called in sequence," declares the page, and then brainfarts and forgets to describe what the sequence is. The language is usually a disorienting combination of technical jargon and ambiguous articles. "Each callable asynchronous method corresponds to a method in the correlated service interface," says one page. The only parts that aren't jargon in that sentence are "each", "corresponds to a", and "correlated". But woe betide you if you can't figure that out after ten minutes of staring at the surrounding paragraphs.
The whole architecture I was working on for the test system, back at Apple - the architecture of Python and Perl driving Apache and RPC calls to present a web service - was inane, for the scale we needed to achieve. For my build system it was perfectly appropriate, though there were still some things that I did the hard way. But for the test system? No. We needed to move to an architecture that would allow us to keep a lot more data dynamically in ram, and share that data between sessions intelligently. This Eclipse environment, plus the Google toolkit, is an excellent platform for that. The only thing Apple has that's similar is their long-in-the-tooth WebObjects platform.
Biologists looking for work are a bit irritated at us programmers. The job openings for programmers at labs are plentiful, and listed right alongside the scant, difficult openings for biologists. It can appear as if us programmers are Terkin Der Jerrrrrrbbbs.