Aehso’s Output

Mike’s reference to Google’s new Web Toolkit piqued my interest. It is quite novel in several ways

• It allow web client developers to code in Java rather than JavaScript. The code is translated prior to “deployment” by a Java-to-JavaScript compiler. The generated Javascript code uses a Javascript-based JRE emulation library that provides “most of java.lang and a subset of java.util”.
• The toolkit UI uses Eclipse SWT and (I’m pretty sure) the Java-to-JavaScript compiler is built on top of the JDT code model. Interesting use of JDT!
• The toolkit ships a command line utility that generates template Eclipse projects. Import the skeleton project into an Eclipse workspace and code away. I had to do a little hacking to use the generated launch configuration file to launch the toolkit from within Eclipse but it works. (Drop a copy of the .launch file into <workspace>\.metadata\.plugins\org.eclipse.debug.core\.launches, restart the workbench and then use Debug… and you’ll see it listed under “Java Applications”). This leads to one of the most powerful features. You can debug your application (as Java) when the toolkit is launched and/or you can write/run JUnit tests. Assuming the toolkit behaves itself when translating it all to Javascript you can be pretty confident the end user experience will be consistent.
• You can mix Javascript into your Java source if things get a little hairy.
• The toolkit uses Tomcat to host the “deployed” Javascript/HTML.
• The Javascript generated code (and library) provides lots of web client development conveniences like browser history management and major browser compatability.
• They’re giving it away for free but they only ship some of the source for the toolkit. It would of course be better if they shipped all of the source for the toolkit itself when integrating that much open source software (Eclipse/Tomcat/Mozilla/Rhino) into a free toolkit. Quid pro quo and all that.

See the overview for all the gory details.

All in all, it is not for the Javascript purists but it looks very handy for all those Eclipse/Java developers out there who occasionally need to knock up a web based application…

aehso dev, eclipse, java

A while back I wrote that perhaps more needs to be done to coordinate the efforts of the various top level projects and the conversation seems to be evolving. Some of the subsequent discussion raised an interesting question – what is the relative importance of producing exemplary tools versus extensible frameworks? The difficulty, it seems, is in striking a balance in developing both.

A quick search (in the Eclipse Bylaws and Development Process) produces the definition of exemplary tools. It is worth reproducing here:

Eclipse Platform tools are exemplary in that they verify the utility of the Eclipse frameworks, illustrate the appropriate use of those frameworks, and support the development and maintenance of the Eclipse Platform itself.

To verify and illustrate the appropriate use of frameworks.

Ed thinks the tools are the basis of the Eclipse phenomenon and I fully agree that JDT was the primary driver for the phenomenal rate of adoption of the Eclipse platform. JDT served as the exemplary tool for Platform and subsequently, under the guises of Eclipse.org, it is evolving as both a best of breed tool in its own right and also as a domain specific framework for reuse by other Java centric projects. The JDT exemplary tools alone are not enough to facilitate the requirements of these downstream ‘consumer’ projects.

(It is also worth remembering that the bulk of the Platform and JDT/Team was created by one organization – IBM’s OTI Labs.  Eclipse.org is a very different organization – an open meritocracy, backed by many commercial interests running many top level projects that are tackling more varied and diverse problem domains.)

Then there are the two other types of consumers that Eclipse.org also services:

• Adapters. These comanies consume projects developed under the auspices of Eclipse.org and
  build derived tools outside of the Eclipse.org umbrella. Adapters consume extension points and also some exemplary tools (e.g. the WSDL editor in WTP). But for the most part adapters are building on Eclipse because of the powerfully integrated frameworks it supplies.
• Users. Those millions of downloads don’t come from nowhere! Users are interested only in taking the output of one or more Eclipse.org projects (or derived products) and consuming them as-is. For example a user might choose to use WTP instead of a commercial Eclipse based IDE like Rational Application Developer or one might choose to use TPTP instead of Rational Functional Tester. These users are mostly interested in free tools – derived commercial tools usually provide more function but at a price.

The danger, in terms of under-investment in framework integration, is faced by the downstream projects, adapters and users. As they consume more top level Eclipse.org projects into a single product they might find themselves inheriting frameworks and/or tools that either do not integrate at all or worse duplicate core functionality. In this case, all the exemplary tooling in the world won’t compensate for the inability to get disparate frameworks from different projects to play well together.

So we can hope this will never happen but with the Eclipse.org project count expanding the risks are escalating and as Murphy’s Law states, “If anything can go wrong, it will”. A neutral Eclipse.org mediation facility may be the only way to ensure that top level projects – that are managed by different concerns that compete on a commercial level – produce frameworks that meet the high standard set by the original Platform/JDT contributions and integrate in a consistent fashion into a larger Eclipse “Platform” (hmm, is there a better term for that?)

aehso eclipse, process

The new Rich Server Platform proposal does seem very interesting – tooling for packaging Web Applications (Java /Lazlo/PHP based) into OSGi bundles and deploying them onto Equinox/OSGi runtimes that are running on remote server VMs.

The goodness here comes from leveraging the OSGi R3 runtime’s dynamic bundle management capabilities to manage the lifecycle of bundles. And of course there is value to some in the fact that the underlying OSGi frameworks are neither Eclipse nor Java centric. So rather than dealing with technology centric deployment and packaging tooling and APIs, server side components are packaged into OSGi bundles and deployed using OSGi’s built in mechanisms. That includes being able to execute an (non-UI) Eclipse plugin on the server side. RSP takes this approach one step further by providing the tooling necessary for users to be able to create applications composed of local and remote bundles (i.e. hybrid RCP/RSP applications). RSP-UI will make this technology a lot more accessible to users.

From a server developers point of view, the OSGi R3 ‘kernel’ is the ideal foundation for dealing with the complex issue of creating an open and extensible server runtime – if only we had the luxury of re-writing existing servers from the ground up to take advantage of it! However, users are already experimenting with running bundles on remote VMs – they’ve even got Equinox running on a Slug and of course there are other OSGi
runtimes out there.

Wolfgang Gehner thinks this is a disruptive technology, and I’d certainly agree that is has the potential to be very compelling for server developers, tools developers and users alike. The problem might be bootstrapping adaption – getting the OSGi core into the server distributions and convincing users to start packaging their components as OSGi bundles (rather than .war files, for example).

I wonder how these initiatives will relate to IBM’s Autonomic Computing efforts.  In a previous incarnation, I had the pleasure of participating in a AC Solution Install working group that was working on providing solutions in a related space (supporting self-configuring servers).  I wonder will the AC toolkits need to incorporate OSGi at their core – I suspect so…

aehso eclipse, java, osgi

Nice, Skype 2.5beta users can now send SMS messages to anywhere in the world for 9c a pop.

By default the Skype userid is sent as the sender’s ‘phone number’ but options allow you to set it up to send your mobile number instead (there is a verification check to make sure you’re not spoofing someone elses).

Now if only the recipient could reply to back to the senders Skype client…

aehso mobile, software

Via RexBlog, this quiz is so true, it’s funny. Has the world run out of unbranded words or is it time to retake the asylum from the the lunatics?

(Wow, I just searched for a link and I can’t find a link to Alan Cooper’s “The Lunatics are running the Asylum” book anywhere. WTF? More people need to read that book…)

aehso internet, web2.0

Via The Cult of the Mac, a stunning iPhone (iTalk) concept video. 

With fans like that it’s a wonder Apple need a design department at all!

aehso mac