Spontaneously Combusting

Is this thing still on?

Just testing the old blog. Since you stopped by, some links:

Mozilla Web Applications

Web Apps are applications that run on any device, and can be distributed through any store or directly by the developer.

The future of Javascript (as visualized by Brendan Eich):

Harmony Of My Dreams

Music notation software: 

How the iPad can revolutionize music notation software

 

 

New language features in JDK 7

Here's a nice overview of new language features coming in JDK 7. Good stuff but nothing most other popular languages haven't had for years. Add type inference and you could have:

ages = {"Arthur" : 42};

ArthursAge = ages["Arthur"];

with type safety intact. Kinda looks like Javascript doesn't it? It's valid python too (sans semicolons). But it could have all the static type goodness of Java with that syntax. Other languages do it.

In addition to the features in that post, a couple of weeks ago Mark Reinhold announced that closures will also be included in JDK 7. After all the wars over closures in Java two years ago and three proposals that went nowhere, this was a big surprise. It turns out that closures are being added to prevent some particularly nasty syntax that would be required for using parallel arrays. Java's ceremonial boilerplate syntax is forcing it to adapt some features that are common in most other popular languages. It's welcome, but too little, too late for some folks. Others would rather that Java not evolve much. Relative stability has served Java well.

Other languages on the JVM already have the features that will be in Java 7 and likely Java 8 and Java 9 too. You could just get on with those if you need those features. That has been my approach, when possible, but at least I know that Java will be moving forward, albeit slowly, when I do have to use it.

JDK 7 has also slipped to later in 2010 so don't expect to be using this stuff in your projects until 2011.

I really like the new features. A function type in Java...never thought I'd see the day.

ECMAScript 5 is official

IBM voted "no" due to lack of decimal arithmetic support. The rest of the planet voted "yes" except for Intel, who didn't have take enough time to review IP issues. The two thirds necessary to approve the spec was achieved along with fast track to ISO. Fortunately, voting "no" doesn't mean that IBM can't implement the new spec in their own Javascript implementation.

The gory details for my fellow language geeks:

http://www.ecma-international.org/publications/standards/Ecma-262.htm

Javascript: SS and otherwise.

Javascript was standardized as Ecmascript but retains it's own identity as the implementation in Firefox. Javascript is Ecmascript compliant but has extensions that may or may not be standardized in future Ecmascript versions. Firefox currently implements Javascript 1.8.1 which is compliant with Ecmascript 3 and E4X. Ecmascript For XML (E4X) implements XML as a built-in datatype making it easy to manipulate XML without using DOM, SAX, XPATH or other XML APIs.

Javascript is an embedded language. Unlike general purpose languages such as C++, Java, and Python, Javascript does not have libraries for common computing resources like file system, network or database access. It relies on the host environment to provide whatever is needed. Javascript does specify how an implementer can include built-in objects that are available at run time and host-provided objects that are unique to each embedding context.

In the browser, host objects include Window and DOM objects. Firefox, much of itself being written in Javascript, provides access to most of the Mozilla platform objects and general purpose objects for local (non-web) applications. These objects included file IO, network IO, password encryption, Sqlite and XUL UI elements. Firefox extensions have access to these objects. Java libraries are also available to Javascript in the browser via LiveConnect. The javascript implementation in Firefox is called Spidermonkey. There are several projects that use Spidermonkey on the server. One example is CouchDB.

In the late '90s, Netscape decided to rewrite the their browser, Navigator, in Java (Javagator). The only piece that was completed and remains today is the Rhino Javascript implementation. Rhino is an actively maintained open source project. Rhino is written in Java and interpreted or compiled to JVM Bytecode. Rhino has both an interpreter and a compiler. The host objects in Rhino include all available Java libraries. Rhino is currently Javascript 1.6 compliant. There are several projects that use Rhino on the server, including a Rails clone.

Javascript on a vritual machine is the same language but with access to all computing resources of the VM rather than the limited, though very useful for web browsing, resources of a security-sandboxed application like a browser.

The Javascript implementation in XPages, like Rhino, is written in Java and executes on the JVM. Host objects provided by XPages include the Notes Java API, and the JSF APIs. Expeditor supports the JEE stack up through JSF so XPJS running on the client would have access to the same libraries.

XPJS is Ecmascript 3 compliant with two exceptions that I know of: @Functions and optional type declarations.

@Functions in XPJS are built-in objects provided by the language implementation. Many of these functions are dependent on the Notes and Java host objects. In order to allow these function names to start with "@", the XPJS language definition was "altered" (hacked!) to allow any identifier to begin with the "@" character. You can write your own function names starting with "@". Please don't. Actually, you can start any identifier with "@" ( var @x = 1; ), but, again, use a namespace object or some other standard convention to keep your functions out of the global namespace.

The other language addition is optional type annotations. This was proposed by Mozilla for Ecmascript 4, so it makes sense that Lotus adopted it in the Workplace timeframe. Since then, events have significantly changed the Ecmascript roadmap and put many of the proposed Ecmascript 4 features, including optional type annotations, in flux. What does the optional type declaration do? It provides the developer with a visual indication of type and the interpreter/compiler can warn of certain type errors. What it doesn't do is include that type information in the generated bytecode. There is no run-time benefit as with statically typed languages. This is consistent with Javascript being a dynamically typed language; all types are resolved at run-time. I confirmed this with the XPages team at Lotusphere.

For several years, there had been two camps battling over the Ecmascript roadmap. One camp, led by Mozilla CTO, Brendan Eich who created Javascript, proposed  a  somewhat radical roadmap that would have added classes, packages, optional type declarations and many other features available in popular general purpose  languages. This roadmap was known as Ecmascript 4. The other camp, led by Microsoft and Yahoo, proposed a much less aggressive incremental roadmap that didn't expand the scope of Javascript beyond the web. This roadmap was known as Javascipt 3.1.

Last year, a compromise called Ecmascript Harmony (Ecmascript ~6) was reached. The Ecmascript 4 camp had to concede some of the more radical changes to reach an agreement and get everyone moving forward. Packages are out. Classes will be implemented as syntax sugar for closures rather than a new construct. Optional type annotations may happen. What about Ecmascript 5? The 3.1 proposal became Ecmascript 5, which is the current draft proposal.

I hope that XPJS will maintain Ecmascript compatibility and perhaps even implement E4X. I know that they would like to do it, but other priorities, including performance, may delay things. I'd hate to see XPages developers using an outdated, non-standard scripting language a few years down the road. Please don't Lotusscript the Javascript. Speaking of performance, InvokeDynamic, the first new bytecode added to the JVM in 14 years is now in early draft review. Dynamic method invocation is about to get a whole lot easier and faster.

So was this just a transparent attempt to express my dislike of "SSJS" to describe XPages Javascript? Yes, it was. I may be too late ;-)

Update:  @headius I just heard there's a good chance invokedynamic will get into a Sun Java 6 update, via a flag and separate rt.jar add-on. [@headius is Charles Nutter, JRuby implementor and Sun/Oracle employee]

Google Wave Protocol coming to the Eclipse Comunication Framework

This will make it easy for Eclipse and/or any Equinox, RCP, or RAP-based application to interoperate with other Google Wave applications.

 Google Wave and ECF

Google Wave - a personal communication and collaboration application and platform

Google announced a personal communication and collaboration application today called Wave. It is also a platform for collaborative applications. Here's some links:

O'Reilly's post

Live Notes from the announcement

Screenshot

Update:

Google Wave Protocol

Google Wave Federation Architecture

Innovation killers

I recently read an article that resonated with me titled "Killing Innovation with Corner Cases and Consensus". Key point:

A corner case is an objection that may be:

1. technically reasonable
2. may have a probability of occurring
3. its probability of occurring is lower than your probability of running out of money

Read the whole thing.

James Governor read it and posted "Corner Cases Can Kill Innovation 2: The Big Dogs Are Too Big" which makes an entirely different point:

...the needs of a tiny minority of customers dictate overall product generation, skewing the overall direction of innovation.

The Innovator's Dilemma comes to mind.

Miss Lotusphere? Try Impact 09.

This is too funny (Lotusphere, South Park):

Come to IBM Impact 2009 in Beautiful Las Vegas, May 3 - 8

Mind blowing browser based UI/App builder

Check out Atlas from 280 North. Watch the video. Then have a look at 280 Slides, a Keynote clone built on the underlying Cappuccino platform. Awesome. Just awesome.

On the future of Lotusscript

There's a lot of noise flying around about the future of Lotusscript (again). Here's my take.

Lotusscript the language as implemented by the Lotusscript compiler has been near-dead for years. NOT dead in the sense that it will be removed from the product but in the sense that there have been so few significant enhancements since R4. There have been some library additions but the language itself has changed less than any other langauge that I use.

What does this mean for the Eclipse Lotusscript editor? Not much. The editor still sends the code as text through JNI to the same old compiler. Don't expect language enhancements just because there are newer and better tools. While I welcome the new tools, I would rather have a better language. Unfortunately, that ship has sailed for Lotusscript.

What I'd like to see but was convinced in Orlando will not happen: Use one or more of existing langauge implementations for the JVM. I'd like to see IBM work through the Not Invented Here and intellectual property issues. IBM uses Jython as a scripting language for Websphere. Groovy is one of the two languages used to build applications with Websphere SMash. The other is IBMs own implementation of PHP for the JVM.

Speaking of IBMs own implementations of languages for the JVM, we have XPages javascript, which is a good example of why I would like to see IBM use existing implementations and STOP building everything in house. XPages javascript is years behind the Javascript in your browser, especially if you use Firefox. (see javascript 1.6/E4X, 1.7, 1.8)

These languages allow you to leverage Java to any extent needed such as domain objects, performance, APIs for third parties, etc. What about "just learn Java"? Yes, by all means..I did, but just as with XPages, a JVM hosted scripting language is often the right tool. (see Ola Bini on Fractal Programming).

Having a powerful, class-based OO scripting language would also reduce the class->prototype->class impedance mismatch that developers moving to Java from Lotusscript have to deal with when using Javascript. I'm not arguing against Javascript, I love the language, but it would be nice to have a class-based OO option (OOption :-?).

The APIs to integrate these language implementations with Java are in Java 6. A tutorial on  how to use the Dynamic Language Toolkit Framework to build Eclipse tooling for them was recently published on developerWorks.

XPages for the client may surprise me. I hope so. And for web apps, the browsers are moving toward other language implementations. Imagine the Run On Server/Client option for Ruby or Python.

This really wan't much about Lotusscript. That's because there's not much to say except "Thanks for the Eclipse tools, they're sorely needed and appear to be very well done".