Annother NetBeans annoyance

NetBeans' search and replace dialog allows you to use regex capturing groups in the find string and regex back references in the replace string. But a naive user, who expected to be able to use something like "\1" and "\2" for his back references, would be sorely annoyed when they didn't work.

Instead, NetBeans uses $1, $2, etc. for its back references. As this person found out after perusing the source code for the search and replace dialog.

The reason, apparently, is because that's what Java regexes do (and Java regexes do what they do because that's what perl regexes do, and always have done). And because NetBeans is primarily a Java-oriented IDE, the Javaness wins out over the regexness, or something.

All of which would be but a minor annoyance, were it not for the information that you're offered when you click the help button in the search and replace dialog, which eventually leads you to a page in the official Java regex documentation that says this:

Back references
\n Whatever the nth capturing group matched

Sigh...

Sun / IBM deal to collapse?

The hot news of the hour seems to be that IBM's bid for SUN is off — they couldn't agree on price. This possibility has been discussed at length in the tech press in the last few days, and the consensus is that this is going to be a disaster for SUN: Schwartz has supposedly hawked it around the whole world looking for a buyer, and (supposedly again) no one expressed interest apart from IBM.

The fear is that, now they know that SUN's top managment has effectively admitted it's unable to return the company to profitability, both customers and employees may haemorrhage away. Some have even hinted that this was IBM's game plan all along — which is not an impossibility, since that used to be Microsoft's favourite trick.

There is perhaps, however, one last, desperate hope: Cisco. The investment boards are humming with the idea that SUN is a perfect buy for Cisco: it would give them an 'in' to the server market, which they have so very recently decided to enter. Hmm, Cisco's new boxes are all Intel I think, and while SUN has a substantial Intel business, its main line is of course Sparc. That said, Cisco is nothing if not an adventurous and technically competent company, and if they decided to run with the Sparc heritage, you might end up seeing a version of the chip ending up in their routers :)))

Sparc has long been almost a millstone round SUN's neck. I'm not quite sure why. ARM has made a major success of a non-Intel chip, with an enormous number of licencees busily fabbing away and integrating it into their custom designs, and I know that SUN has been willing to make the IP available to fabricators in what seems to me a similar way (the devil's in the details though) but so far, only Fujitsu has taken it up. Maybe they were myopic about targetting the architecture at the server market: maybe they should have focused more on scaling Sparc down as well as up. They did that a little bit, aiming it at multi-chip webservers, but perhaps they could have gone a bit further than that.

Whatever. It's now looking, with the benefit of hindsight, as though Java has been an enormously costly mistake for SUN. Not that it hasn't been a very successful platform — it has. But because they've never managed to make more than small change from it, while it's sucked up an enormous amount of management (and, in the early days, legal) time and effort that would perhaps have been better spent on SUN's core competencies.

I say that with a good deal of regret, and as a fan of Java. And of course, it didn't look like that in the early days. Java, originally developed for set top boxes, came out at a time when Microsoft ruled the desktop even more than now, when Microsoft had all the mind share, and when it had started to stop making versions of Windows for desktop and server class processors other than Intel's. The worry was that a Microsoft future would be an Intel future, and that Sparc would go the way of MIPS. Java then, with its virtual machine and processor-agnosticity, was a way of keeping Sparc in the game. But somewhere along the line it got too important, and SUN ended up chasing a mirage.

The brave investor then, might wait for SUN to fall below $4, even as far as $3, and then buy in the hope of a Cisco offer. Or even the hope of the board kicking Schwartz out the door, which would be bound to have a salutary effect on the share price, even if only temporarily.

Google Chrome - what, no coffee?

Well it was here when they said it would be, and I downloaded it. It installed, and crashed at the last minute when the browser had just started up and was importing settings and bookmarks from IE and Firefox, and it looked like it was the bookmarks that were responsible.

But, just like it says on the box, only the tab that was doing the imports fell over, and I was able to carry on and start browsing the web immediately. Later, I went to the options menu and got it to load the bookmarks again, and this time it completed without incident. So score +1 for Chrome.

So what about this blazingly fast Javascript engine then? I've deliberately refrained from running any official tests, on account of being lazy, but just let's say that I'm once again impressed at just how important network and server latency are in the browser experience. That is to say, working with Gmail and Google Reader, sure it seemed a little bit faster at opening the pages, but even in these Javascript-heavy apps, it's the I/O that's the bottleneck.

I decided to look at plugin support. Flash/Flex is there as you might expect (what with having to support YouTube and all!) but, very surprisingly, Java was absent. I managed to find some pages with applets on by going to the Sun website (what a blast from the past!) and got a message saying "No plug-in available to display this content". Here's one of the pages I tried, see what you get.

At first I was a little staggered. Could the status of Java applets have fallen so low that Google weren't even going to bother supporting Java in the browser? (And see here for what I found out about current antipathy to Java in the browser.) Well yes it could, I suppose. Maybe Google have simply concluded that Java in the browser has had its day.

I expect though that the explanation is simpler: Chrome is a beta after all, and there's no compelling need for Google to support applets from day one in the same way that YouTube makes it necessary for them to support Flash. Also maybe something technical about the way the JRE integrates with the browser makes it harder to support than Flash? Maybe. But Safari 3.1.2 (as kindly downloaded for me by iTunes when I wasn't paying attention during a product update) seems to have managed it without any problem. Hmm, this smells kinda bad, kinda fishy...

Of course, Google have got a JVM of their own though, haven't they? Maybe instead of incorporating the Sun product, they'll simply port Dalvik to run inside Chrome? That would unify two of their platforms very nicely indeed, thank you. Android games running in Chrome tabs? I'll have some of that!

If I were Google though, I keep it very quiet if that was indeed my plan, since it would undoubtedly cause a massive outcry (assuming anyone still cares, which is moot, but I bet a lot of people who didn't really care would still enjoy complaining for its own sake). In fact, the best way to do it might be to release Chrome without any Java support at all, and wait for annoyed voices to demand it, and then say something like "Well licensing restrictions mean we can't support yer actual Sun Java in Chrome, but we got something 'ere that's just as good, honest guv'nor."

---

Update: OK, panic over, Chrome does support Java! You just have to have the absolute latest, bleeding edge development release, version 6 update 10. If you click on the toolbar menu and then on the Help submenu it'll take you to a page where you can search for Java support, and that'll take you to a page where they explain what's going on. Or just take my word for it and go to http://java.sun.com/javase/downloads/ea.jsp and download and install Java SE 6 Update 10. Phew!

Still think Android apps in Chrome would be a great idea though.

Google Chrome. OH. MY. GOD.

Apologies for the quality of this post. There's so much to say and my thought processes are just running all over the place as various connections are being made. I've just read about Google's new Chrome web browser tonight, it's all over the web.

My first reaction was, "How odd!" Why would Google want to bring out a new browser? There are new browsers appearing all the time, and it would be much more in keeping with G's modus operandi to date for them to simply help out with advice, code and a bit of cash here and there, rather than to up-end the whole apple-cart like this.

Then I read the 38-page cartoon that they sent out explaining things. And my second reaction was, "Oh. My. God."

It seems obvious now that development of current browsers was either not going in the right direction for Google, or just wasn't getting there fast enough. Things are scrappy. They're fragmented. Google have big plans for the browser, and it looks like they've decided to start bringing all the strands of their work together, so that we can begin to see the shape of what's coming.

Strands? Heck, let's change metaphor. It's like when the tide starts to come in on a nice warm beach. At first all you can see is tiny rivulets of water coming from all directions and going in all directions. It's only later you realise that THE SEA is on its way and your little spot in the sun is soon going to be under six feet of water (and yes, Microsoft, it is you on that towel).

So they've made all these little moves. And they looked a bit odd and a bit disconnected. Google Apps — a bit slow, a bit underpowered, but they would be see, 'cos they're running in a browser. GWT — what's the point of a development environment that has you writing web apps like they were desktop apps? Gmail — nice example of what you can do with Ajax, was it written using GWT? Android — what browser does it use?

But now Google are bringing out Chrome, whose intent seems to be to run applications as complicated as the most complicated ones that you run natively on your operating system, and to run them just as fast (or at least, in the same ball-park). Hmm, Google Apps, they're going to be a bit snappier now, aren't they? Hmm, I can see the point of a big-iron development environment based on a typed language now! And Android, currently sporting the browser that Chrome is based on, will likely be running Chrome or a Chrome-alike in the next release (after the one that we still haven't had yet).

That's enough hot air and pontificating. The rest of this post is specific reactions to things in the cartoon, which you may not understand unless you follow the link above and read the cartoon.

---

They are using the Webkit code base. Not Mozilla. By my reckoning that's now about a million billion important new browsers have been built on webkit, versus ... erm ... (I can't think of any) built on the Mozilla codebase. OK, so I'm using "important" in a very particular sense: "big", that is to say, backed by an organisation (probably a commercial company) and guaranteed a large user base. (And I know that there are lots of browsers based on Mozilla, but together they must have a user base approaching, what, 10,000 people?) [Yes, other than Mozilla itself and Firefox.]

Mozilla are #?*&ed! Now the flow of money from Google to the Mozilla foundation is not charity, it's a deal whereby Mozilla preferentially funnels its searches to Google. So that can stay in place. As long as Mozilla users search on Google, Mozilla can get money out of that deal, there's no sense in Google just killing it. So Mozilla is not #?*&ed immediately then, but stand by to see it lose market share vertiginously if Chrome is as good as Google thinks it's going to be.

Stand by also to see Microsoft scramble to match Chrome in terms of features. This comes at a particularly bad time for Microsoft, with IE 8 code very likely closed to new functionality, and the release only a few months away [GOOGLE SMACKS MICROSOFT, #1]. What do MS do now? Do they stick to the original release timeframe and release it as-is, and smart when nobody notices because Google released a better browser a few months back [and that's TOMORROW folks!] and everybody's using it? Or do they pull the release and desperately try to match Chrome, feature for feature?

Omnibox. I can see this running into trouble very quickly. This business of remembering what site-based search boxes you've used, and allowing you to reuse them by typing in a site identifier and then a tab and then your search terms? Think of the controversy caused by deep linking a few years back. This is an excellent way to cut a website's search page out of the loop. So now, instead of first going to Amazon's home page and having to skim over all the stuff they've kindly prioritised for you as your eye hunts for their search box, you'll go straight to their results page. Hmm. Site publishers are going to regard this as kidnapping their search boxes, and I would be surprised if there weren't a few legal challenges to it soon.

Interesting to see the places in the cartoon where they have obviously decided to put the wind up the competition. Some of them really made me chuckle.

On page 4 they say that each tab is a separate OS process. If memory serves, Unix/Linux processes used to be lighter weight than Windows ones. Assuming that's still the case, Chrome may be a bit sprightlier and more performant on Linux than on Windows [GOOGLE SMACKS MICROSOFT, #2] — just the thing for those Linux-powered net-tops that are springing up all over the place.

On page 5 they point out that this means that the sort of badly-behaved page that used to make your entire browser crash will now only affect the one tab. This must happen to me about once a day at least: four separate browser windows open, themed for work-related stuff (several pages of documentation from assorted sites), news (Google Reader for scanning, then I open up any interesting stories in their own tabs), mail, and one for anything else; that's twenty or thirty pages all open at once, some of them regularly updating in the background. When a bad page takes down that lot it's annoying and I thank heaven for Firefox's auto-reopen feature. When the bad page is really bad, and Firefox goes down again straight away as soon as it tries to reopen it, that's when I get annoyed.

Pages 9-11 must be putting the fear of God into Microsoft right now. Google are showing off how they can push automated Chrome testing out over their famous distributed server network, testing tens of thousands of web pages per hour [GOOGLE SMACKS MICROSOFT, #3] and making sure that they cover them in order of importance, as indicated by their very own page ranking alogrithm.

Page 13 is very interesting. They mention no names, but I immediately thought of Adobe's Tamarin VM for Javascript, now donated to Apache. Were they thinking of Tamarin? Did they look at it and reject it, or was it not open source back when they decided to write one themselves? I need to look at the timescale for that more carefully. One thing: Tamarin is built for the version of Javascript that didn't make it into the new standard, and work is apparently under way at Apache to convert it for the version that did. Good luck with that. Google probably thought it was better to start from scratch [GOOGLE SMACKS ADOBE]. And if the boys that did the new Javascript VM are more or less the same ones that did the Dalvik VM for Android, then Google probably thinks it can do a damn good job on its own, and rightly so.

Interesting also that they are seem to be JIT-compiling Javascript to machine code. That's been a perilous way to go in the past, partly because of what can happen with variables. Javascript variables are untyped, but the values that they hold do have types (number, string, object, ...). Now there's nothing to stop me coding a for-next loop where the value held in some variable used inside the loop changes type on each pass through, and in the past that's either killed efforts to compile Javascript or put serious constraints on the efficiency of the resulting code (by making it have to be too general).

In this context, it's especially interesting to look at the latest release of the Google Web Toolkit (GWT). GWT you will remember lets you write your web application in Java, a heavy-duty, strongly-typed language, which GWT then "compiles" to Javascript for actual execution in the web page. The release notes for the latest version of GWT noted that this "compilation" phase effectively throws away the valuable type information, in the transformation from typed Java to untyped Javascript, and that in previous releases this negatively impacted performance. But the current release takes advantage of the fact that any Javascript variable in a web page produced by GWT is guaranteed to have come from a typed Java variable! In other words, you can guarantee that that sort of type-bending naughtiness isn't going to happen in a respectable GWT application. So you can do type inference based on the first value of a variable that you see... And then the release notes said that that had led to sundry improvements that were beyond my understanding, because all I could think of was that Javascript was still untyped.

So what's the betting that GWT-produced web applications will run especially well in Chrome, because of the good behaviour of their variables (and, no doubt, for many other reasons way above my head)?

---

Michael Arrington at TechCrunch says:

Make no mistake. The cute comic book and the touchy-feely talk about user experience is little more than a coat of paint on top of a monumental hatred of Microsoft.

I hope this doesn't mean that MS have got so far under Google's skin that they are letting hatred guide their actions. That would be a colossal mistake. So far, Google have been the nimble players. They are the ones who, in every case [May not be true. I have a terrible memory!], have led the way with an unexpected paradigm-shift, leaving others scrambling to catch up. Letting Microsoft-hatred guide your actions is a mistake other companies have made in the past, and it's ruined them because it hands the initiative to MS, who are not slow to capitalise on the opportunity.

---

Update: Dave Methvin over at Information Week points to where Google may have got some of the technology they are using to sandbox Chrome tabs.

GWT and GAE

One always looks, of course, for the ideal toolkit with which to develop AJAX-style web applications. It's a pastime into which one can put as little or as much effort as one desires, and it rarely seems to result in satisfaction. In that, it resembles the search for happiness... but I digress.

Some toolkits promise much and deliver little. Many seem focused on flashy effects rather than functionality. Most seem to have large and inexplicable gaps ("surely they must have realised they would need to..."). You end up combining, or trying to combine, different kits that are built on different principles and have no unifying structure, and whose subtle interactions lead to difficult bugs.

I'd more or less settled on YUI (The Yahoo! User Interface Library) as having the best functionality for my purposes. It's a bit heavy and a bit clunky, and new developments spend entirely too long in beta, but it's comprehensive and versatile, even powerful. I use it in the editing application for gedsguides.com.

Along the way, I'd had a look, along with everyone else, when Google brought out the Google Web Toolkit. An interesting approach: compile a Java source to a Javascript runtime (the delicious irony didn't go unnoticed — the Java you'd write using the GWT would once upon a time have run natively in a JApplet). The potential was obvious, as were the potential gotchas: differences between the development environment (a Java runtime) and the production environment (in-browser Javascript) might lead to severe debugging problems.

Happily, the quality of engineering that went into GWT seems to have been high enough for it to have garnered a good-sized community, so maybe the fears were overstated. There's even a version of Ext JS available for it, Ext GWT to give it a bit of extra pizzaz in the GUI. The combination seems excellent and I'm nerving myself up to rewriting a page of the GGW Admin Console with it, as a test.

Another area where GWT shows evidence of independent creativity is its approach to cross-browser compatibility. Most other toolkits, insofar as they attempt to solve this problem, approach it by abstracting it away the differences. The result is that they invariably have a base module that has to be loaded by the browser, and that translates their general code into browser specific calls, for whichever browsers are supported. This module needn't be very large, 10 to 20 kilobytes perhaps, but it does have to contain code paths for all supported browsers. And that's a reasonable price to pay for the independence it provides.

The reason all the Javascript toolkits have to adopt this approach is because they are entirely runtime, browser-based affairs. GWT offers the same browser independence to your code, but this is a pre compile-time affair! GWT then produces lots of different run-time support files for your app, one set of files for each browser (even, for each version of each browser). The end result is that the Javascript footprint of your application, when it actually runs in a particular browser, may be much smaller than with other toolkit: each browser has to load only the code that it needs. Extremely smart. The cost of course is that your server has to have room for tons of files; your application takes much more space on your server's disk than with the other approaches; there may also be an impact on your server's cacheing. These are all things that we know how to solve on the server though, and they play to its strengths; all in all, I rather like the balance that GWT has adopted.

Here's the Achilles heel. If your web application needs to contact the server for data (which, given that it's a web app, it's bound to do a lot of!), then the support that GWT provides for RPC on the server is implemented using Java servlets. This means that your server has to be Java based: Tomcat, or Resin, or JBoss or whatever. This is a matter of a particular implementation rather than anything essential of course, though there's a fair bit of work for anyone that wants to re-implement the server-side stuff using something like, say ... Python.

Why would anyone want to re-implement GWT's server side using something like, say ... Python?

Well say hello to Google App Engine! I remember getting very excited when this came out: "run your web applications on Google's infrastructure"! Who wouldn't want to do that? This would be instant death to the thousands of tiny ISPs who host millions of modest LAMP sites. The sort of stuff that uses a MySQL database for small amounts of data. Things like game guild sites with membership lists of a couple of hundred people, raid calendars, little bits of news and so on. (I still think it will impact these things severely, but over a much longer timescale than I first thought.)

The thing is that App Engine is Python-only. Lots of people have been wondering if it's possible to combine GWT, which is mostly a browser-client (AJAX) technology, with GAE, which is mostly a server techology. Trivially it is, since the pages you serve from your GAE web-app can contain anything of course, including GWT applications. But that only works with the most basic of applications. If you need to pass data between the AJAXy GWT application running in your browser and your server, then GWT wants to talk to a Java servlet. Or you could jettison GWT's preferred approach (RPC) and go for something RESTful (there's a JSON example app comes with the GWT SDK). In which case a Python back-end is as good as anything else; it's very doable, but there'd be somewhat more coding for you if you did that.

So Google need to adopt a more joined-up approach to web applications. They could commit to writing a GWT-compatible back end in Python and running on GAE. That's not such a bad idea; it migh even be the least work for them. Make it a compiler option, with a flag saying if its server code should be emitted in Java for Tomcat et al. or in in Python for (Django and) GAE.

Don't look for Protocol Buffers to help here though, even though it's touted as "Google's Data Interchange Format". Although Protocol Buffers already supports both Java and Python (that is to say, the supporting tools can emit code in both those languages) it's a binary wire protocol: suitable for slinging data around on an internal network, but not so good for (typically text-based) conversations between a browser and a web server, especially if there's a firewall in the way.

Update. Note that Google App Engine uses Protocol Buffers internally, to communicate between the application (i.e., your web app) and the App Engine server, and between the App Engine server and the BigTable servers (all internal to Google's private network see? — exactly the use case envisaged in the previous paragraph).

Web 2.0 RIAs - the brave, new world.

I've spent my free time over the last couple of days looking at Adobe's Flex technology, and the ecosystem surrounding it. I'd always known about Flash of course, and I'd read the occasional article on Flex, Flux, AIR or whatever Adobe is calling it nowadays (they seem to have a really high churn rate on products, or maybe it's just product names). But as a Java guy, I'd never been able to understand what was wrong with the good old applet — perhaps not the very oldest, AWT-based applets, but certainly the (slightly) newer Swing-based JApplets. Sure, the flash-based stuff looked good, but I didn't see anything I couldn't do with Java.

So I was in for a bit of a shock. Java, which let's remember invented the whole idea of sectioning off a rectangle of window and offering it as a UI to a program embedded in the web page, seems to have completely lost the minds and hearts of browser-side developers. Java developers of 10 or more years standing are saying that Flex is the way to go for RIAs (rich internet applications) now.

It seems that after a decade of Java programming, while Sun has more or less abandoned the browser and chased the server, people have finally given up waiting for usable in-browser technology. Sun let themselves be distracted by Microsoft, and failed to see that Adobe was quietly taking their market. Applets still look clunky, they still have funny fonts, they still take forever to load, as the browser has to load and run the complete JRE (at least)... Meanwhile the Flex developers have noted all these failings of Java and quietly ensured that Flash/Flex doesn't suffer from them.

Well the market was Sun's to lose, and they lost it; indeed, they seem not to have cared about it at all. I suppose you could say that Sun was a more server-oriented company, while Macromedia and Adobe were more desktop oriented. But Sun has always made workstations too... It's shocking really: for a fraction of what they must have spent buffing Java for the server, they could have licensed some decent fonts, told a few designers to make the graphics look sleek and sexy, and licensed a decent codec for movies. Instead they jumped aboard an ill-conceived server-side beans bandwagon and ended up producing the J2EE monstrosity — its latest addition, Java Server Faces, piling yet another badly designed, badly implemented and altogether half baked piece of cack on top of all the rest.

(I mustn't go on about JSF, but please, someone tell me, when the entire rest of the industry was conspicuously moving towards client-side processing, with first DHTML and then Ajax, why did Sun adopt a model where even little things like a combo box dropping down its list portion required a complete page refresh from the server? What idiot thought that was a good idea?) ... I'd better rest a while, and wipe some of the froth away from my mouth ... I'll be alright in a moment ...

So, yes, I wasn't prepared for the degree of, frankly, hatred of in-browser Java that I found, even amongst ex Java developers. Like lovers who've been deceived, strung along, and humbled once too often.

But serious questions remain. A long time ago, early on in browser-centric Java, Sun spent a lot of effort on the Java sandbox. A poorish initial implementation gave way to a flexible one with fine-grained permissions, one that eventually most people felt they could trust. I've not done a lot of reading about Flex, but I haven't heard anything about sandboxing. I understand that it does have one, but I haven't heard any discussion about how good it is. And then of course, the entire world + dog moaned at Sun to open source Java, and it's finally done someting about it. Beyond open sourcing the basic flex product, Adobe has kept all the value-add stuff and the flash player itself closed. If Flex/Flash becomes the standard delivery mechanism for RIAs, Adobe will make a lot of money and we'll all wish we had stayed free.