Friday, December 22, 2006
I also met two Sun colleagues Thomas Enebo and Charles Oliver Nutter, two of the JRuby core developers, and brainstormed a little bit with them about the support of JRuby in OpenOffice.org. JRuby comes directly with Java in the future and the integration work into NetBeans is ongoing. So it would be great to have a good support for JRuby from UNO as well. JRuby as one of the main scripting languages for OpenOffice.org with a smart integration in NetBeans is a really cool idea and I hope that we can deliver something in this direction. We will see what's possible and when!
Some interesting podcasts from Javapolis (including quite a few on agile development) are here.
Wednesday, November 08, 2006
- Tamarin project page
- Mozilla foundation press release
- Executive summary and analysis by Frank Hecker of the Mozilla Foundation
The VM architecture looks like this:
But again, it's not really about .swf, it's about compiling JS2 into bytecode, which is an incredibly important advancement.
Brendan Eich held an IRC chat yesterday in which he and Kevin Lynch of Adobe fielded questions about Tamarin. A few interesting factoids came to light:
- Acrobat's JS engine will move from Spidermonkey to Tamarin.
- The expansion factor for jitting bytecode to x86 is roughtly from 5X for strongly typed, early-bindable code, to 20X for loosly typed, unbindable code. Thus, you pay a price in memory hunger for the ability to JIT-compile JS, but JS2's new typing system mitigates it somewhat.
- The Tamarin codebase comprises 135,000 lines of C++ (smaller than I would have thought). This is sure to grow but Brendan Eich indicated very strongly that Firefox needs to shrink, not grow, hence there will be pressure to keep Tamarin as lean and efficient as possible.
- Tamarin is not 64-bit-ready. But if the project gets the kind of (huge) traction that it appears it will get in the community, the "64-bit Flash" question may finally get solved. And maybe ES4/JS2 will get a "long" data type in addition to int/uint/double. ;^)
Thursday, November 02, 2006
Tuesday, October 24, 2006
There's a list of open-source fuzzers here.
Friday, October 06, 2006
Although this move is certainly consistent with Adobe's longterm Flash strategy, I don't think it's motivated by anything Flashy. (Call me naïve.) Adobe already supports SVG in most of its products and will soon leverage SVG in Acrobat via PxDF. Support for SVG goes on. Just not in the browser.
The move mostly affects Internet Explorer users, since SVG support is native in Firefox. But let's face it, how many IE users even have the Adobe plug-in? How many IE users have ever tried to view an SVG page? (How many can even spell SVG?)
I don't blame Adobe (or any company) for abandoning a development-intensive non-product that requires huge gobs of time and money to support. But that raises the question: Why doesn't Adobe donate its Viewer code to the open-source community? This is a great opportunity, after all, for Adobe to win badly needed points in the F/OSS world. From a P.R. standpoint, it's Something Very Good.
Surely they'll figure it out.
Wednesday, September 27, 2006
Tuesday, September 26, 2006
If you're still scratching your head, I recommend spending some time with Alice.
Monday, September 18, 2006
Try this test page. On my machine, Firefox 126.96.36.199 will load that page in 8 seconds, which is about 7.99 billion clock cycles too many, for my taste. But Internet Explorer locks up for a full 30 seconds (consistently, every time) when trying to load the page.
I'm happy to see IE users brutally punished in this fashion, of course. But honestly, this has to be some kind of sick, sick joke, right?
Wednesday, September 13, 2006
Nevertheless, it seems clear that the fruits of JSR-292 will be folded into Dolphin (Java 7, to be released in 2008).
Let's see, that's (how many is it?) thirteen years that it took Sun to realize some people may actually want to do serious programming in something other than you-know-what.
Tuesday, September 05, 2006
Rhino engine. Rhino has a history of following the ECMA standards quite closely, and the JS1.7 features are not part of any standard (yet).
Of course, none of this will be in Internet Explorer any time soon. Once again, the Firefox folks have made a bold move into unexplored territory, leaving the safe, comfortable, Web 1.0 weenie-world of Ballmer & Co. ever further behind.
Thursday, August 31, 2006
The chapters are individually downloadable, or you can shag the whole book. For a quick look, I recommend Chapter 11 (which had me utterly spellbound).
Tuesday, August 29, 2006
Implementing this for even a small subset of SVG will be arduous. (The Flash ninjas must be laughing themselves sick right about now.) I'm tempted to dismiss Dojo 2D as a quixotic quest. But I also know AJAX developers are clamoring for just this sort of thing, and I'm sure Dojo 2D will be a scandalous success.
Performance is apt to be underwhelming (SVG is already sluggish enough without wrapper layers), but that's never stopped a market disruptor before, and anyway, Dr. Moore can't be far behind with the cure.
Monday, August 28, 2006
I finally found the ultimate no-frills super-lightweight 3D library written in Java: Peter Walser's idx3d framework. (Freeware, of course.)
After playing with idx3d for a month, I'm still astonished at how much functionality Peter crammed into just 29 (count 'em) .java files. The code is streamlined and easy to follow (a rarity in 3D engines). No frills, no baroque overfactoring, no "let's be fully general so as to handle the occasional weird-ass edge-case even if it means slowing everything else down."
I've found the idx3d code to be extremely stable, reasonably fast (again, a rarity in Java 3D engines), and after 30 hours of flogging it mercilessly in Eclipse (on Novell SUSE Linux Enterprise Desktop), I have yet to see an OutOfMemoryError.
The most wonderful thing about Peter Walser's code is that it was written in Y2K (back when Java was lean and mean) and has very few JRE dependencies: you'll see an occasional java.util class, but for the most part, Walser's code files contain no imports. Which is astonishing.
If you're interested in 3D programming, check this thing out.
Wednesday, July 26, 2006
As it turns out, the guy who did the amusing boredom-graph cartoon (see yesterday's blog) also has written one of the best overviews of hashing I've seen in a long time. Be sure to see his excellent Hash Functions and Block Ciphers page as well.
Study the material on Bob's site. Save yourself years of meditation.
Tuesday, July 25, 2006
Monday, July 17, 2006
why not just shorten it to
Verbose closing tags are a pure waste of space (albeit required by XML spec). Abbreviated closing tags don't make the file any less parsable. When the parser encounters </> it knows that the closure is at the nesting level of the previous opening tag. If not, the XML was not well-formed to begin with.
Verbose closing tags are just that. Unneeded verbosity.
Wednesday, June 28, 2006
I'm not so much talking about static identity info, like your Social Security number (which will be worthless anyway in a year or two). I'm talking about the really interesting dirt. Your shopping habits, reading habits, movewatching habits, hobbies, favorite travel destinations, where you went to school, who you've worked for and how long you stayed at each job, and (let's not mince words) sexual preferences, who your friends are, the names and ages of your children. Most of this info can be scraped, right now today, from blog bios, online resumes, mySpace profiles, tag-sharing sites, social networking sites (like linkedin.com), and photo-sharing sites. Your info is out there. You put it there yourself.
And the bad part is, there's no taking it back. Google archives old pages. So does the Wayback Machine.
You're leaking personal info to the world every time you use an online service of any kind. Particularly the spate of Web 2.0 applications offering free online word processing, spreadsheets, chats, etc. Those are hosted apps. Most of the hosts are trustworthy (arguably), but the hosts tend to archive chatlogs and other interaction records, which means the storage media on which that material is archived can be stolen or lost just like the Veteran's Administration guy's laptop.
Or it can be inadvertantly indexed by Google and exposed to searchers (as has happened with supposedly private test scores).
The outflux of identity info onto the Web is massive, and it's accelerating daily, driven largely by the explosion in popularity of "Web 2.0" apps.
All of which is great news to the National Security Agency, who by some accounts are sifting through your data right now.
Tuesday, June 20, 2006
Thursday, June 08, 2006
Surprisingly, most of the comments at the end of Lee's blog are dispassionate, logical, and in full agreement with Lee's premise, which (to oversimplify) is that Spring is cryptic, over-architected, and malodorous at a code level (among other felonies), begging the question of why anyone would use it.
I can understand why Lee would feel that way. He's right on most counts. Spring is indeed byzantine and heavy (as most things surrounding J2EE are), and buries too many dependencies in XML. But that doesn't mean Spring doesn't have its legitimate uses.
Monday, June 05, 2006
Abstract: A virtual machine, such as a Java(tm) virtual machine, is configured to operate as a web server so that users, using a browser, can make general-purpose inquiries into the state of the virtual machine or, in some cases, mutate the state of the VM. A "browsable" VM contains a network traffic worker, such as an HTTP thread, a services library, and a VM operations thread, which is an existing component in most virtual machines. The network traffic worker and the VM operations thread communicate through a request data structure. The VM operations thread generates a reply to the request upon receiving a request data structure from the traffic worker. Such a reply can be in the form of an HTTP response containing HTML or XML pages. These pages are transmitted back to the browser/user by the network traffic worker.
Thursday, June 01, 2006
A checker can be as simple or as sophisticated as you want it to be. Maybe you want to be sure that every call to foo( ) is eventually followed by a corresponding call to bar( ). Or you may have application-specific security concerns (in the context of export laws, perhaps). Or you may have company policy around certain syntactical idiosyncracies that would only be of specific concern to your department or your company.
Interestingly, the Stanford MC guys did a pass against the Linux kernel using their own custom checkers plugged into their own MC-aware gcc and found almost 600 potentially serious bugs, most of which have not been looked into yet (if you believe Coverity's latest findings).
Wednesday, May 31, 2006
Tuesday, May 23, 2006
Of all the recent posts on this surprisingly controversial subject, I find Curtis Poe's the most clueful.
Friday, May 19, 2006
I spent 30 minutes fooling with it. Everything came out looking like Pia Zadora.
Wednesday, May 10, 2006
Odd thing is, it even worked for us when we set the URL to a secure wiki page inside the company firewall.
We promptly exited our Gabbly session and began chatting about it on Groupwise Messenger (our company standard). The whole experience was freaky and left us with serious security worries. Especially when Firefox crashed on me within minutes of leaving the Gabbly-iframed page.
The thought of people using a 3rd-party-hosted chat app like this at work scares the hell out of me.
But that's the trouble with things like shorttext.com, ajaxwrite.com, and other free-neato-trendy AJAX "services": They require you to rely on the trustworthiness of the host. I put it too delicately. These are man-in-the-middle applications.
Thursday, May 04, 2006
Friday, April 28, 2006
Unlike a lot of Web2.0 apps, Zoho is not the product of a teenager locked in a closet. Behind the Z-suite is a ten-year-old company, AdventNet, with offices around the world.
This is starting to get exciting.
Thursday, April 27, 2006
Tuesday, April 25, 2006
Wednesday, April 19, 2006
I'm not a Python person so I didn't realize (until after Googling around a bit) that the so-called microthreads of Stackless Python are a way of achieving the same thing.
The key intuition behind stacklessness is that you move everything that would normally be kept on "the stack" out to a data structure on the heap. Therefore one thread can jump between potentially tens of thousands of execution frames.
The ability to run huge numbers of processes concurrently is obviously important in many kinds of applications. If AJAX becomes another driver of this technology, it'll be interesting to see who'll be first to implement a stackless-Java virtual machine.
Thursday, April 13, 2006
Wednesday, April 05, 2006
I'm looking at it in OpenOffice, so just for fun, I tell OOo to do a regex-search on
and globally replace that with zilch, thereby wiping out all comment lines.
The result? With comments, Oracle's Core.js file is 140 KB. Without comments: 95 KB. Imagine: almost 50K of comments in a 140K file.
I don't think I've ever seen such well-commented code in any language, ever.
It turns out Oracle has been publishing its own best-practices advice on "Partial Page Rendering" since 2002.
Friday, March 31, 2006
"Within Sun, Java is not viewed as a satisfactory language for the construction of commercial applications."
"That our Java implementation is perceived as inappropriate for many uses is supported by internal documents and policies."
A great, great memo, filled with priceless insights.
One of my personal favorites:
"Our experience in filing bugs against Java has been to see them rapidly closed as 'will not fix'. 22% of accepted non-duplicate bugs against base Java are closed in this way as opposed to 7% for C++."
A particularly noteworthy aside concerns one engineer's desperate quest to circumvent resource exhaustion on Solaris Servers by implementing a particular daemon using J2ME code (yes, that's right: J2ME).
You have to read this memo for yourself. If you're like me, you won't know whether to laugh, cry, or go to work for the circus.
Thursday, March 30, 2006
Then I realized the Web was RIFE with examples of people trying to bring continuations support to various web frameworks. In fact, continuation servers are sprouting all over the place, with funny names like Seaside, Wee, Lakeshore, Continuity, Borges. Written in a variety of languages.
So why the fuss over continuations? The short answer is that it offers an elegant way to keep track of session state in a multi-user client-server app. You end up writing code that looks compact, linear, and obvious, rather than the typical MVC pasta-pile.
But the benefits go far beyond elegant state management. There are payoffs in scalability and efficient use of resources as well.
If you want to grok the basic paradigm shift (and you have time to read only one article), invest a few minutes reading this brilliant minitorial. You just might have a Mega-Aha Moment.
Wednesday, March 29, 2006
The basic notion of a continuation is that it lets you exit from a scope (using neither a return statement nor a "throw" nor a continue nor a break), go do something else, then reenter the original scope as if nothing happened. In fact, if you serialize the continuation, you can come back months later, and continue in a new thread.
It may help to think of a continuation as a snapshot of the current call stack and program counter. The main intuition is that if you can save off enough information about the current execution context, you can reenter that context at your leisure, kind of like hitting Play again after Pausing a video to go make popcorn.
The concept of continuations has been around a long time. In fact, the formalisms around continuations were invented in order to talk meaningfully about the goto statement. But the goto entered lexical leper status after Dijkstra famously savaged it. By 1980, no self-respecting programmer (outside of the Scheme community -- a leper colony in its own right) would speak the word aloud, much less use it in a program.
And yet, goto is a reserved word in Java.
The reason continuations are important to Web 2.0 is that they hold the key to making AJAX scalable. Continuations enable a threadless polling architecture that would be hard to achieve (cleanly) any other way.
I'll have more to say on continuations. In the meantime, if you want to wrap your head around it further, I strongly recommend reading about Cocoon's use of continuations.
Tuesday, March 28, 2006
The full Google <canvas> compatibility script is at http://www.abrahamjoffe.com.au/ben/canvascape/canvas.js.
Test it out on Canvascape.
Friday, March 24, 2006
Thursday, March 23, 2006
I suppose it's just a matter of time before Google steps in and moots both offerings.
But let's pull back for a minute and look at this carefully. Suppose you were to substitute the name "Microsoft" for Sun/Amazon/Google. Would you trust your online computing and storage needs to Microsoft, at any price?
Then why would you put that kind of trust in Sun, Amazon, or Google?
Monday, March 20, 2006
Someone asked David Heinemeier Hansson whether he thought SOAP had legitimate uses or was, to the contrary, simply evil. DHH tactfully replied that SOAP mostly seems unnecessary. "So SOAP feels more like the doorknob to the gates of hell," he concluded. "In itself, a doorknob is hardly evil. But once you turn..."
But let us not forget, it's more than just a language. And therein lies the hitch.
Steve Yegge (now at Google) put together a refreshingly non-religious series of posts about various programming languages that, in one incarnation or another, can run atop the JVM. As an exercise, he wrote a simple game program, then ported it to various languages, then wrote about the experience.
Steve's appraisal of Java resonates with me. "Java has lots of wonderful features," he observes, "but Java isn't one of them. Java's appeal as a platform for doing real work rests precisely on its strengths as a platform, not as a language."
Hypothesis: Sun's greatest contribution to the history of computing is the 'VM', not the 'J', in JVM. The 'J' part is, like a 10-year-old Ford Taurus, beyond economical repair. Yet the world continues to use it, due to virtual-machine lock-in. The barriers to exit are just too high.
Friday, March 10, 2006
Some important Web 2.0 architectural memes are starting to come together in the form of things like Feedflare API, Ning Atom API, and shortText.com. (If the latter would expose a REST API, it could become the Clipboard of the Web instead of merely the Notepad of the Web.) What's interesting about the Feedflare API is that it involves late evaluation of embedded XPath, giving mashers a nice combination of declarative and imperative styles to draw upon. They also silently cast your RSS to Atom at parse-time.
As more and more powerful mash APIs come on the scene, and as people normalize on Atom as a datagram format, JSON as an object-passing/serialization format, things like shortText.com for clipboard storage, etc., Web 2.0 reaches an architectural maturity level where the likelihood increases that someone will create the "killer app" that finally tips the tipping point away from IE (for good), towards Firefox, Opera, and the Web 2.0 compatibles . . . thereby locking Microsoft out of a Web 2.0 future (if it isn't locked out already). The coming "killer app" will no doubt leverage one or another IE-incompatible technology such as <canvas> and/or E4X and/or Greasemonkey and/or SVG and/or some other cutting edge technology that's fully available in Firefox/Opera but not in IE.
Mark it as a future I-told-you-so.
Wednesday, March 08, 2006
It pretty clearly says that GIMP needs to suck a lot less.
Secondly, it tells me Adobe Systems doesn't really care about the Linux market (much less the community).
Adobe's Pam Deziel admits that the shrinkwrap giant has known for some time (well before the Novell survey) about the pent-up demand for a Linux version of Photoshop, based on its own research.
So in other words, Adobe has known for some time that it could make money tomorrow by offering a commercial version of Photoshop on Linux. It chooses to leave this money on the table (shareholders be damned). Not a big enough market, says Adobe.
How, then, does Adobe explain the fact that it currently offers a Solaris version of FrameMaker 7.2? FrameMaker has nowhere near as many users as Photoshop, and Solaris is nowhere near as popular as Linux.
Adobe's story is nowhere near making sense.
Sunday, February 26, 2006
Remember that for this to work as a bookmarklet, it all has to be on one line. I've broken the code apart here for illustration purposes.
All we do is make array out of the individual location elements of the current URL by breaking it at forward slashes, then pop the tail element off, re-join() the array with '/' delimiters, and make the browser go to the newly formed URL.
Works like a charm.
I keep this script in a link button (called "Peelback") on Firefox's linkbar. It's handy as heck when you've landed on an interesting web page and you want to further navigate a given URL via the ancestor axis.
Friday, February 24, 2006
Which is doubly ironic when you consider that until recently, Digg itself was reportedly an XSS risk.
Note: Every verb on this page should be considered to be prepended by "allegedly" unless otherwise indicated.
Tuesday, February 21, 2006
So what is it, then? It's simply a way to serialize a web page and its contents, making the page 100% self-contained (with no reliance on outbound links). Images are stored inside the page in data:url format (see RFC 2397), which of course makes the whole scheme incompatible with IE. Then again, the Adobe SVG plugin for IE does support data:url, so it may be possible for some clever soul to write a script that uses embedded SVG islands to work around this IE limitation in semi-transparent manner. So to speak.
Thursday, February 16, 2006
But code size is not the only issue. O'Callahan dives quite deeply into the architectural waters and comes up with refreshingly brash statements like "XPCOM is a disease ... people acquire it by being exposed to infected code." He bristles at the notion that a single SVG <rect> element requires 1.2 Kbytes of pointer storage and carries around empty transformLists. (One wonders what he would say about Java, wherein a mere JPanel has 330 methods.)
The real problem, of course, is the SVG spec, which defies any attempt at elegant implementation.
Bring on sXBL with a <canvas> binding.
Wednesday, February 15, 2006
Monday, February 06, 2006
The fact that there are Novell customers with well over 100 million objects in their FLAIM-backed eDirectory trees should tell you how scalable and robust the FLAIM technology is. (It should be robust, after nearly 20 years of development!)
If you want to get a feel for what XFLAIM is all about (given that I can't do it justice here), go to the documentation.
Is this Novell's first step toward open-sourcing eDirectory? Quite honestly, I don't know. (If I did know, I couldn't write about it here.)
Thursday, February 02, 2006
It's obvious that something like this is sorely needed and will be widely used (and abused). I give the ATF proposal ten thumbs up.
While I expect ATF to sail through Creation Review (and thus become an active Eclipse.org project) with nary a hiccup, I can't say the same thing about the newly proposed Kabuki Project for incubating Zimbra at Apache.
The Kabuki Proposal has not been 100% warmly received over at ASF. The debate has included criticism of Zimbra's code (for being too Java-like, poorly namespaced, bloated, not working correctly out-of-the-box) as well as criticism of Zimbra's lack of community presence, inability to find non-salaried committers, etc. One gets the impression that Zimbra expected that Apache.org would jump on any well-established AJAX framework donation. Evidently not.
What's ironic is that the IBM guys took the ATF Proposal to Apache first before putting it in front of the Eclipse.org WTD group. (I can't recall IBM ever taking an Eclipse technology to Apache for incubation. Can you?) Gory details here.
Wednesday, February 01, 2006
The issue is this. E4X has a dot-syntax for XML objects that allows expressions like
root.x.y to obtain the
y element under an
x element under the root. But when an element name contains a hyphen, this syntax breaks. Consider:
var fragment =
// Now try to access the display-label value
var value = fragment.field.display-label; // ReferenceError!
The interpreter treats a hyphen as a minus-sign, of course, and since
labelhasn't been declared, it's undefined and unusable. If a variable named "label" does happen to exist in the current scope (e.g. you used
var labelin place of
// Instead of this:
var value = fragment.field.display-label; // ReferenceError!
// Do this:
var value = fragment.field["display-label"]; // "Please approve."
There's one more syntax breakage to deal with, and that involves the descendant-retrieval syntax. E.g.,
root..y returns a list of all
y descendants under
root, regardless of what level in the tree each one is at. This syntax obviously breaks down if
y is something like
// Instead of this:
var allLabels = fragment..display-label; // error!
// Do this:
var allLabels = fragment.descendants("display-label"); // list of nodes
Similar breakages and workarounds exist for E4X attribute syntax, the details of which are left as an exercise for the reader.
Sunday, January 29, 2006
// create E4X XML object
e4x = <div>Hello World!</div>;
// serialize it
serialzed = e4x.toXMLString();
// create DOM object
( new DOMParser() ).parseFromString( serialzed, 'application/xml' );
// make it into a string again
serialized = ( new XMLSerializer() ).serializeToString(dom);
// back to E4X XML object
e4x = new XML( serialized );
Eventually we can expect to see support for a syntax like e4x = new XML( dom ), but this has yet to be implemented in Firefox.
Thursday, January 26, 2006
The number of declared namespaces has grown since .sxw days. Even in the smallest .odt file, you get this:
<office:document-content xmlns:office="urn:oasis:names:tc:opendocument:xmlns:office:1.0" xmlns:style="urn:oasis:names:tc:opendocument:xmlns:style:1.0" xmlns:text="urn:oasis:names:tc:opendocument:xmlns:text:1.0" xmlns:table="urn:oasis:names:tc:opendocument:xmlns:table:1.0" xmlns:draw="urn:oasis:names:tc:opendocument:xmlns:drawing:1.0" xmlns:fo="urn:oasis:names:tc:opendocument:xmlns:xsl-fo-compatible:1.0" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:meta="urn:oasis:names:tc:opendocument:xmlns:meta:1.0" xmlns:number="urn:oasis:names:tc:opendocument:xmlns:datastyle:1.0" xmlns:svg="urn:oasis:names:tc:opendocument:xmlns:svg-compatible:1.0" xmlns:chart="urn:oasis:names:tc:opendocument:xmlns:chart:1.0" xmlns:dr3d="urn:oasis:names:tc:opendocument:xmlns:dr3d:1.0" xmlns:math="http://www.w3.org/1998/Math/MathML" xmlns:form="urn:oasis:names:tc:opendocument:xmlns:form:1.0" xmlns:script="urn:oasis:names:tc:opendocument:xmlns:script:1.0" xmlns:ooo="http://openoffice.org/2004/office" xmlns:ooow="http://openoffice.org/2004/writer" xmlns:oooc="http://openoffice.org/2004/calc" xmlns:dom="http://www.w3.org/2001/xml-events" xmlns:xforms="http://www.w3.org/2002/xforms" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" office:version="1.0">
Notice, in particular, the xforms declaration. It's there by default now, mainly because any .odt can double as an xform.
More of which, later.