Joe Walker - future tag

Big Question for Sun

Mon, 19 May 2008 12:35:45 GMT

It looks from the outside as though every spare resource that Sun has is going into JavaFX. JavaFX may or may not win against Flash/Flex/Air/Silverlight/Android/Ajax, but while Sun is concentrating on FX, it doesn't appear to be giving the Java language the updates it badly needs.

Maybe Sun sees Java as 'done'. OK, but the Java language has one of the largest developer communities in the world, and they'd like some direction. Where do Sun recommend they go for their server-side development needs in 5 years time?

Maybe Sun think we should change to JRuby, Scala or Groovy. Maybe there are updates to Java that I don't know about. If none of the above are the case, the community will eventually disappear into mish-mash of languages that doesn't have the strength of numbers.

3:19pm Update: tweaked last paragraph to make the point clearer.

DWR: State of the Union

Thu, 20 Dec 2007 13:20:08 GMT

So DWR is now part of the Dojo Foundation. I thought it would be good to quickly summarize where we are, and what I'm working on, and to give everyone a chance to comment.

DWR 2.0 has been out for 6 months or so. At the time, I swore that the next release would be a small one, called 2.1. However it appears that I’m not good at swearing because there is lots in the next release - I think we’re going to have to call it 3.0.

Just as a quick recap, here’s what changed with 2.0:

Reverse Ajax which I define as Comet or Polling or Piggyback, whichever works best.
Spring Namespace support, Guice support, Annotations etc.
etc. Every release needs some etc. See the release notes for more.

Since 2.0, we've been working on the following adding support for JSON, Bayeux, images/binary file upload/download, a Hub with JMS/OAA support and more reverse ajax APIs. I also want to get some Gears integration going.

There are also a whole set of non-functional things to consider:

Moving the website to directwebremoting.org
Restart chasing CLAs, using a foundation CLA rather than a Getahead CLA
Get some lawyer to create a CLA so Getahead can grant rights to the Foundation (or something similar)
Get someone to pony up and let us move to SVN
Unit tests

DWR Hub and integration with JMS and OpenAjax Hub: We have a hub, along with one way integration with JMS. The OpenAjax portion will be simple except for the getting the OpenAjax Hub to work smoothly with JMS part.

Reverse Ajax Proxy API Generator: The goal with this is a program that will take JavaScript as input, and output a Java API which, when called, generates JavaScript to send to a browser. Some of this work has been tricky, but then meta-meta-programming was always bound to be hard. This currently mostly works with TIBCO GI, but more work will be needed to allow it to extract type information from other APIs. You can see an example of how this is beginning to evolve in yesterday's article at The Server Side. I hope we will be able to create some Dojo integration for 3.0 too.

JSON support: One goal is a RESTian API so you can do something like this: http://example.com/dwr/json/ClassName/methodName/param1/param2 and DWR will reply with a JSON structure containing the result of calling className.methodName("param1", "param2"); It would be good to support JSONP along with this. We might also allow POSTing of JSON structures, although I’m less convinced about this because it quickly gets DWR specific, and then what’s the point of a standard. Status - DWR has always used a superset of JSON that I like to call JavaScript. We do this to cope with recursive data, XML objects, and such like. I’ve done most of the work so that DWR can use the JSON subset, but not created the ‘handler’ to interface between the web and a JSON data structure.

Bayeux Support: Greg Wilkins (Jetty) committed some changes to DWR, which need some tweaks to get working properly. Greg still intends to complete this.

File/Image Upload and Download: This allows a Java method to return an AWT BufferedImage and have that image turn up in the page, or to take or return an InputStream and have that populated from a file upload or offered as a file download. I’ve had some bug reports that it doesn’t work with some browsers, also we need to find a way to report progress to a web page simply. See this post on Ajaxian for more.

DOM Manipulation Library: Currently this is limited to window.alert, mostly because I’m not sure how far to take it. There are a set of things like history, location, close, confirm that could be useful from a server, and that are not typically abstracted by libraries.

Gears Integration: I’ve not started this, but it needs to take higher priority than it currently does. It would be very cool if DWR would transparently detect Gears, and then allow some form of guaranteed delivery including resending of messages if the network disappears for a while.

Website: We need to get the DWR website moved away from the Getahead server, and onto Foundation servers. There will be some URLs to alter as part of this, and I don’t want to lose Google juice by doing it badly. The documentation for DWR 2 was not up to the standards of 1.x, and while it has been getting better, we could still do more. One thing that has held this back has been lack of a DWR wiki. I hope we can fix this with the server move.

Source Repo: We are currently using CVS hosted by java.net. They support SVN, but want to charge us a few hundred dollars to upgrade. I expect to move away from collab.net/java.net CVS some time early next year.

Unit Tests: I've been trying for ages to find a way to automatically test with multiple browsers and servers. WebDriver looked good for a while, but it doesn't look like the project is going anywhere particularly quickly, so I'm back trying to get Selenium to act in a sane way.

Etc: There's always 'other stuff'. I've particularly not gone into things like Grizzly support. There's plenty of etc in this release too.

Browser Wars

Mon, 17 Dec 2007 15:38:23 GMT

Alex:

To get a better future, not only do we need a return to “the browser wars”, we need to applaud and use the hell out of “non-standard” features until such time as there’s a standard to cover equivalent functionality. Non-standard features are the future, and suggesting that they are somehow “bad” is to work against your own self-interest.

Ten years ago, in 1997, some people spent ages getting DHTML pages working across IE and Netscape, and when we were done we felt dirty and bruised. Some of us crawled back into our caves resolving that stabbing ones-self repeatedly with a sharp object was more preferable.

However, some people saw it as an opportunity.

In 2007, the people that saw it as an opportunity have created Dojo, YUI, JQuery etc. So this time around we're ready for them, and it doesn't have to hurt. This time around it's a matter of waiting for Alex, John etc to have taken all the pain and revved the frameworks.

The Hardware of Tomorrow Versus the Platform of Tomorrow

Tue, 23 Jan 2007 20:48:33 GMT

It seems to me that there is a problem. The OS/platform of tomorrow is not designed to make good use of the hardware of tomorrow.

The Hardware of Tomorrow

In 2003 the hardware race was about GHz, and the clock wars. AMD and Intel competed on their clock speed, and people checked off clock speed advances against Moore's Law. In 2006 the battle lines began to be re-drawn around cores rather than clocks; Dual Core became the norm for new processors, and the next generations of chips from both AMD and Intel will be steadily increasing the number of cores. Intel and AMD have slightly different strategies, Intel is going for more generalized processing units, AMD (having bought ATI) are choosing to make their processing units more specialized.

So the hardware of tomorrow is going to work best with software that encourages multi-threading. Java's memory model and util.concurrency make it technically strong, and Billy Newport thinks that framework developers will need to alter their APIs to take advantage of the threads. He's probably right, but I suspect that to do a proper job, we're really going to need a language that builds multi-threading in at a lower level, leaving the compiler with the job of creating multiple execution paths. However that's not going to be quick.

Cringley 2007 Prediction 5:
AMD and Intel continue to beat the crap out of each other with customers gaining but wondering why there is no software that supports those new 8-way processors, as both compilers and third-party developers fail to keep up.

Knowing this, Cringley's 2007, prediction #5, is a bit of a no-brainer.

Today, even just dual cores, one core spends a lot of time idle. Anyone spending any time waiting for javac to do it's work will be wishing it did a better job of using more than one processor. The "multi-threaded is hard" problem is one of the things killing the PS3 now. The PS3's cell processors seem to be too advanced for most of the games manufacturers right now.

So if the hardware of tomorrow is going multi-threaded, what about the platform that developers use to write software?

The Platform of Tomorrow

I don't think we are in for any radical changes in platforms in the next few years. We'll continue to have a mix of Windows on the corporate desktop, Linux in the server room, and MacOS for developers, and arty types, and none of them being the primary development platform, which will continue to be the web.

The web is the default place to develop new software these days. If you need raw speed, hardware access, 3D, off-line usage or top-quality OS integration, you'll use something else, but for everything else there's the web.

The problem is that web-browsers are a step backwards as far as multi-threading goes. In Javascript there is no such thing as a new thread, and worse than that, the entire platform (i.e. a browser) runs a single JavaScript thread. If a script in one window goes into a tight loop, or runs some synchronous Ajax then the browser HTML display freezes.

So are the any solutions?

Adding thread primitives to Javascript might technically possible, but it seems to me to be impractical; the single-threaded assumption is built fairly deeply into many applications.
It might be possible for browser manufacturers to create a thread per domain. I don't see how this could cause problems, but I'll admit that I have a suspicion that I'm overlooking something. If it does work then it might be possible to allow developers to create new threads by dynamically creating iframes in other domains and having some safe way to communicate between them.
There is a Javascript pre-compiler called Narrative JavaScript that looks like it might be of some use: it contains a spawn() method to start a new thread of execution. It's written in Javascript so you can deliver the pre-compiler to the browser or deliver the output. However until there is support for something like this at a language level that can exploit newer hardware, it doesn't solve the problem.

The solution that I'd like to see is a language emerging that pushes the job of creating threads to the compiler, that runs on the JVM, and that is available in all browsers. I think I can safely predict that this is not going to happen any time soon though.

So maybe the biggest challenge to Ajax is that compared to desktop applications they are going to look slower and slower as other platforms are quicker to embrace tomorrows hardware.