Roberto Chinnici's Blog

Community: Java Enterprise Archives

More fun sessions at and around JavaOne

In addition to the Java EE 6 talks, there are a few more events on my calendar for the week of JavaOne.

On Sunday, when I'm not caught up in rehearsals and last-minute slide editing, I'll check out the GlassFish Unconference and party. Since the agenda is entirely up to participants, bring your best topics and suggestions!

On Monday, I'll be at CommunityOne. As Tim Bray pointed out, it's free and packed with great talks, so you'd be crazy to spend the day elsewhere.

On Tuesday at 3:20pm I'm doing a session on "JavaScript: The Language Everybody Loves to Hate" (TS-4986).

In this talk I'll try to convince a predictably skeptical audience that JavaScript is a real programming language. I'll focus on functional and object-oriented programming, explaining all the arcana. The samples I'll show are mostly taken from popular frameworks, like jQuery, Prototype and jMaki. I'll also touch on some smaller topics, like modules and fluid interfaces. The focus is not on Ajax programming, so I will not cover browser differences or DOM at all, just core language concepts and how they scale. By the way, as I prepared the slides I thought of expanding this material into a series of blog entries. If you are interested, please leave a comment.

On Wednesday at 9:30am I'll be at "The Script Bowl: A Rapid-Fire Comparison of Scripting Languages" (PAN-5435).

Somehow I got persuaded to act as a judge in this American Idol-like elimination show. I'll try to keep my snide remarks to a minimum and I promise not to try and affect a British accent. Charles Nutter broke the embargo on the super-secret list of tasks that our panelists have been asked to perform. But he may have got the list of participants wrong: we will have JRuby, Jython, Groovy and Scala representatives on stage, ready to dazzle the audience with their best work.

In the rocket science department, on Wednesday at 2:40pm I'm registered to attend a session on "Transactional Memory in Java Based Systems" (TS-6316). A bit dry maybe, but ten five years from now this stuff is going to be everywhere, so you may just as well learn about it today.

On Friday, at 12:10pm I'll attend Kohsuke Kawaguchi's Hudson talk (TS-6547) to pay homage to this irreplaceable tool and its equally irreplaceable author. I think that without Hudson all software development around here would stop; furthermore, at the rate it's spreading Hudson will soon run the entire software industry. Not too shabby for a butler!

Finally, after much session and party attendance, I plan to end the week on Saturday at the Scala Lift-off unconference (no ties to JavaOne). Right now I'm more interested in Scala than the lift web framework, but in any case it's going to be a great opportunity to meet other Scala-heads.

Overall it looks like a great (and exhausting) week in the making!

Java EE 6 at JavaOne

JavaOne 2008 is around the corner, so I thought I'd compile a list of sessions touching on Java EE 6 technologies.

Let's start with the platform itself.

As part of the Sun Technical General Session (Tuesday, 1:30pm) I'll be giving an overview on EE 6 and show some cool GlassFish V3 demos. Then you are all invited to the Java EE 6 Platform Community BOF (BOF-4984, Wednesday, 7:30pm) to talk about profiles and other features in the platform. Several expert group members will be there (12, at last count) and we are looking forward to a very interactive conversation with the audience.

Moving on to the main EE 6 components, here is a list of talks by the various spec leads:

• TS-5343 EJB 3.1 (Tuesday, 12:10pm)
• TS-5509 JPA 2.0 (Wednesday, 1:30pm)
• TS-5415 Servlet 3.0 (Thursday, 10:50am)
• TS-5425 JAX-RS 1.0 (Tuesday, 12:10pm and Friday, 2:50pm)
• TS-5979 JSF 2.0 (Thursday, 2:50pm)
• TS-5286 WebBeans 1.0 (Wednesday 10:50am)

(I just noticed the overlap between the EJB and JAX-RS talks. I wonder if it's too late to move one of them, or schedule a repeat session. I'll check with the conference organizers.) Update: The JAX-RS talk will be repeated on Friday at 2:50pm.

I would also recommend the session on JSR-303 (Bean Validation, TS-5616), which we are tracking closely for inclusion in the platform.

Finally, here are the community discussion BOFs:

• BOF-5624 Connector Architecture 1.6
• BOF-5039 JDBC 4.1
• BOF-5753 EJB 3.1

If you like the demos I'll show during the keynote, you owe it to yourself to attend the GlassFish V3 session (TS-5921, Tuesday 4:40pm).

Extensibility and modularity

Thanks to everyone who left comments on my previous blog entry on profiles, as well as on the related TSS and InfoQ articles. Also to the 700+ folks who voted on the poll on java.net or commented on it either on-site or on TSS.

At a high level, I have to say that the feedback reflects quite closely the discussion in the JSR-316 EG. Perhaps the EG composition is even more representative of the whole community than we originally thought!

Unfortunately, the poll results are a masterpiece of indecision: large preference for including JSF 2.0 and WebBeans 1.0, but short of a majority (46.7%). A smaller profile without JSF and WebBeans at 28.9%, but even that camp is split nicely in two (at 17% and 11.9%). A full 24.2% of respondents who don't care.

Conclusion #1: There is strong demand for JSF 2.0 and WebBeans 1.0.

Conclusion #2: We cannot please everyone (we kind of knew that).

Having read all the comments, there seems to be a bit of confusion about the way that extensibility would work. In my original blog post I didn't go in depth into it, mostly to avoid breaking the record for the longest and most boring blog entry on java.net, but the subject deserves a few more words.

For clarity, I find it convenient to distinguish two cases, based on whether a technology can be added to an application by a user or by a server vendor. I will reserve the term "extensibility" for the first case, and use "modularity" for the latter.

Extensibility

At first sight, making it possible to add any technology via extensibility seems desirable. (Incidentally, this may well be the Spring tack on the whole thing.) In reality, this would require a lot of contracts to be standardized. Since standardization has a cost and the returns would be diminishing, I doubt that it will ever cover 100% of the functionality. Performance-wise, going through standard contracts at this level of granularity may turn out to be sub-optimal, so I imagine there'd always be an incentive for vendors to bundle the implementation of certain APIs with their application server to try and squeeze every bit of performance out of it.

At the same time, extensibility is a great thing if it captures the 20% of functionality that covers 80% of the needs, thus enabling a lot of developers to painlessly use a lot of technologies at essentially no cost in complexity or performance. In essence, this is the reasoning behind making extensibility in the web container a key goal for Java EE 6.

A lot of the APIs we've been considering for the Web Profile can be handled via extensibility: drop one jar into the WEB-INF/lib directory of your application (or in some suitable shared directory on your server) and you get JAX-RS, or JSF, or JPA, or WebBeans, or server-side JAX-WS, or... The key factors here are the availability of the technology in standalone form (which requires a separate TCK to exist) and the adequacy of the extensibility contracts in the servlet container. We certainly want to make sure that the latter are sufficient to plug in pretty much any web framework worth using, so please keep an eye on the Servlet 3.0 developments and let us know if you find any holes. On the TCK front, we are resource-constrained on what we can do with respect to existing technologies, but for new ones (including all the ones listed earlier) we will make sure suitable TCKs exist.

Modularity

The second case, modularity, covers pretty much everything else. In a number of cases, which hopefully will get smaller over time, there is no independent TCK for a technology, so an implementation cannot consist a jar separate from a full Java EE server. In some other cases, there is no standard contract that would enable you to plug an arbitrary implementation into an application server. (EJB 3.1 is a good example.) Designing these contracts is non-trivial, so we need to accept as a fact of life that we won't have them in Java EE 6. Luckily, we got a bunch of new contracts done recently, e.g. the security-related ones in JSR-115 and JSR-196, so things are moving in the right direction.

As part of the work on profiles, we've been trying to improve on the situation as much as time and resources allow. In the case of EJB, we've been prodding the EJB EG to define a "lite" subset of EJB 3.1 which can be run on top of the Web Profile. This way, application server vendors will be able to offer a "EJB 3.1 Lite" implementation in their Web Profile products even if we went with a "small" Web Profile (e.g. option (A) in my previous blog entry).

So, why am I using the word "modularity" for this case? It's because it fits well with the trend we are seeing towards more modular application servers like GlassFish V3. Rather than having a monolithic server, you'd be running a small core and an initial set of containers, with some baseline functionality. You could then download/install/activate as needed any number of new modules providing additional functionality, like EJB 3.1 Lite. Of course, you could handle this way modules that use extensibility too, especially when they are shared by multiple applications, but for things like EJB 3.1 Lite there literally wouldn't be another option: absent an SPI, the choice of what EJB 3.1 Lite implementation you run would be limited by what your server vendor offers.

Reality bites

Once you look more closely at the different APIs, you start realizing that there are some "gray" cases too, like JPA. In fact, although it's possible to add JPA to a web application via extensibility, your application will be restricted to using the SE-based programming model (i.e. using the javax.persistence.Persistence class as an entry point). Enabling the resource injection-based EE model is non-trivial and would require quite a bit of work. Is the SE model good enough? Does extensibility have to go all the way in all cases? I hope not, but it will take time to figure out where to draw the line for maximum effectiveness.

As a coda, I should talk briefly about JAX-WS. It wasn't very clear in my previous entry, but since Java EE 6 requires Java SE 6, the JAXB and JAX-WS APIs would be present in *any* profile. Unfortunately, what's left out is the ability to define web service endpoints on EE, which traditionally follows the JSR-109 model. We'd like to see this case handled via extensibility, so that it'd be possible to drop a "server-side JAX-WS" jar into WEB-INF/lib and have the application work in any servlet container, especially those that don't support JSR-109. In this case, we'd also like this extension library to use the version of JAX-WS that comes with the JDK. Currently there are some missing bits in the JAX-WS API that prevent this from working, but we're looking into adding a small SPI for this purpose to the JAX-WS 2.2 release.

Profiles in the Java EE 6 Platform

Update: See the related stories on The ServerSide and on InfoQ.

It's been several months since my last update on the work going on in the Java EE 6 Platform Expert Group (JSR-316).

The main topic of discussion in the EG has been profiles. There are several aspects to this, ranging from the number and contents of profiles to the somewhat more general subject of SPIs and pluggability.

By the far the most animated part has been the discussion around the Web Profile, with several definitions being proposed. Personally, I found it very interesting to see how EG members crafted their proposals by following different routes and aiming for somewhat different goals. This is a testament to the activity and liveliness of the platform.

At this stage, we think that the best path forward consists of polling the community for feedback on which definition of Web Profile they'd most like to see adopted by the expert group.

One reaction that people sometimes have is to ask: Why should we choose? So, as a premise, I should point out that profiles come at a cost. As the specification lead for JSR-316, Sun is responsible for delivering a Reference Implementation (RI) and a Technology Compatibility Kit (TCK) for each profile. Additionally, Sun needs to take all the legal and business steps to license the platform and each profile, provide support to licensees (including no-cost support for qualified ones), etc. This does not come for free.

In very practical terms, then, we cannot support a large number of profiles in the desired timeframe for the Java EE 6 platform. Here "large" really means "more than one".

Not all is lost though. One of the driving ideas around profiles is to move away from a big-bang model for the delivery of the platform, enabling smaller, focused communities to forge ahead in the context of a profile they define. It is natural then to achieve as much decoupling as possible from the beginning and push profiles into separate JSRs, to be finalized on their own timeline.

This said, we originally proposed defining a Web Profile as part of the Java EE 6 JSR because (1) it's helpful to have a use case at hand when developing the notion of profiles, as opposed to doing so in the vacuum, and (2) we believe that there is interest in the market and in the community for a web-centered profile of the EE platform. Incidentally, the amount and depth of EG mail that the Web Profile generated more than proved the first point.

To come to the central part of this post, here are the two profile proposals that got the most interest in the EG. I've tried to come up with a characterization of them in five words or less, but in the interest of not attaching strong labels or identifying the proponents, in what follows we'll simply call them A and B. As a reference, I also listed the contents of the full platform in the third column.

In (B), the inclusion of JSF 2.0 and WebBeans 1.0 is controversial, so we marked them with an asterisk (*). Not coincidentally, these are technologies which could be handled via extensibility (keep reading for more details).

Some clarifications are in order.

"EJB 3.1 (Lite)" refers to the idea of allowing implementations to deliver a subset of EJB 3.1. The contents of this "lite" subset are wholly undecided at this point, but as an example it might include the annotation-based programming model introduced in EJB 3.0, restricted to session beans with local interfaces (only). In other words, you could write an annotated session bean with a local interface and use it in your Web Profile-compliant product (assuming (B) is accepted, that is). But, for example, you could not write a EJB 2.1-style session bean, or an EJB 3.0 message-driven bean, or a EJB 3.0 stateful session bean with a remote interface.

It's important to note that proposal (B) assumes that "EJB 3.1 (Lite)" will exist, but this is a decision that is entirely up to the EJB 3.1 expert group (JSR-318), where it's going to be prioritized against other features. The precise definition of what comprises "EJB 3.1 (Lite)" is also left to the EJB 3.1 expert group, with no particular proposal being put forward as of today.

A second point worth discussing in some detail is related to extensibility, which you may remember is one of the goals of Java EE 6. As a feature, extensibility interacts with profiles, allowing some interesting scenarios to be played out.

First of all, in the web tier extensibility refers to the ability of taking advantage of third-party frameworks with a much simplified programming model. Developers won't need to manually edit the web.xml descriptor to add context listeners, filters, servlets and servlet mappings per the instructions given by their favorite web framework. Rather, adding a third-party jar to the web application will trigger the addition of all these elements, with no developer intervention. We expect that this feature will cover the requirements of all major web frameworks such as JSF, Struts and Spring MVC, scripting solutions like JRuby on Rails and Grails, WS-* web services following the JAX-WS 2.0/JSR-109 model and RESTful web services written to JAX-RS 1.0. One important point to note here is that extensibility is agnostic to whether a technology is based on a JCP standard or not.

Extensibility though is not limited to web technologies. Looking at existing JCP standards, it's going to be possible for a product that implements the Web Profile to also include additional technologies. The required precondition is that the technology in question must have a standalone TCK. This applies not only to technologies which are independently defined, but also to those who are required components of the full platform.

For example, assume that JAX-RS 1.0 (JSR-311) becomes part of Java EE 6. None of the two Web Profiles (A/B) includes it as a required component. Still, since JAX-RS 1.0 plans to offer a standalone TCK, Web Profile products may decide to offer support for it out-of-the-box. The difference with the case of a developer dropping a jar file for a JAX-RS implementation into the WEB-INF/lib directory is that the vendor of the Web Profile product would have certified the JAX-RS implementation and would presumably be supporting it.

Currently, not all technologies in Java EE 5 have a standalone TCK. For example, neither EJB 3.0 nor JTA 1.1 do. As part of the conversation in the EG around profiles, we at Sun have offered to make many more TCKs available in a form that is suitable for running them on a Web Profile product. These include TCKs for technologies like EJB 3.1 Lite, JTA 1.1 and Connectors 1.6. We believe that this will empower application vendors to ship Web Profile-compliant products that offer more than the minimally required technologies, to help bridge the gap with the full platform.

As an aside, I should point out that the recent trend toward more modularization in application servers will work very well with extensibility, by delivering a simpler, more effective way to manage the versioning and availability of libraries to applications.

As we expand the freedom to combine technologies in a product, the issue of compatibility requirements that span multiple technologies comes to the fore. For example, the Java EE 5 specification contains requirements that servlet containers must honor wrt the availability of JTA. The plan for Java EE 6 is to rewrite such requirements so that they will apply to any profiles and implementations thereof that contain the relevant combination of technologies. Going back to the example, any product conforming to any Java EE profile that includes both servlets and JTA will have to honor those requirements. The rationale has two components: on one hand, we think that the Java EE requirements add significant value to standalone technologies, as testified e.g. by the large number of servlet containers which implement JTA in a way that is compatible with what Java EE mandates; at the same time, calling out the requirements will help ensure that applications that target profiles will work on the full platform. Overall, this makes profiles more than just collections of independently tested technologies, because those technologies will be tied together in interesting ways, deliver more functionality than they would on their own.

This brings me to the last point I'd like to make. One concern we heard around profiles is that they might weaken compatibility. Essentially, if my application targets the Web Profile (however defined) + JAX-RS 1.0, then it won't run on any plain Web Profile product. Although that's technically true, it's important to recognize that there is an upward compatibility guarantee in the form of the full platform, at least when the added technologies are required components, as JAX-RS is. This is no worse than (and, in fact, better than) the current compatibility story for, say, servlets + Struts.

We do expect though that, whatever choice is made re the Web Profile, we may enter an "experimental" phase in which products with different feature sets will compete in the Web Profile space, until one feature set prevails. I'd describe that development as welcome and look forward to standardizing the winning feature set in a future Java EE profile. The Web Profile itself may evolve in the future by adding more technologies (but not by subtracting them, except via pruning), based on experience acquired after its first release.

It's also the case that the full Java EE 6 platform will always be there, offering an ample choice of certified Java EE 6 products from different vendors, to address needs that go well beyond what the Web Profile offers.

GlassFish on SoyLatte on Tiger

It's great to come back from vacation and find out that open source has worked its magic once again. Landon Fuller's SoyLatte port of JDK 6 and OpenJDK to Mac OS X now runs on Mac OS X Tiger and is sufficiently stable to allow me to run GlassFish v2 on it seemingly without any problems. I tested it with a few Phobos webapps and they ran just fine, as did the admin console.

The path to having the SoyLatte work integrated in OpenJDK is still long, but as long as you can put up with the licensing and compatibility limitations (i.e. at development time), it's a great step forward. Now you don't have to be hostage to Apple's maddening mishandling of the Java community for your work. As retribution for Apple's behavior, an upgrade to Leopard looks even less compelling now than it did before.

Currently SoyLatte supports Swing via X11, a far from optimal path, but if you want to run your favorite IDE on SoyLatte you should check out Fabrizio's blog. (Unlike GlassFish, NetBeans requires SoyLatte to be installed under /System/Library/Frameworks/JavaVM.framework/).

I guess the scariest part of the whole thing is the set of licensing hurdles that Landon had to clear to make this happen. At least it looks like things will be much simpler for JDK 7, thanks to its GPL v2 license. In the meantime, kudos to Landon and please OpenJDK folks do not drop the ball on this!

Java EE 6 Platform (JSR-316) Update

In the spirit of transparency, I'm going to be posting regular updates on the work of the Java EE 6 expert group (JSR-316).

For the most part, this is going to be a condensed version of the updates that are sent to registered observers to the expert group. In order to join as an observer, you need to be a JCP member. The instructions to join the observer list are on the JSR-316 community update page (JCP access required), also linked from the publicly accessible JSR-316 detail page.

Starting with some trivia, the expert group is fully formed now, and it counts twenty-five members plus the two spec leads.

The following issues were discussed and resolved:

• Application client class loading - The Java EE 6 specification will clarify that classes and resources belonging to an application client are isolated from other modules present inside the same ear file. This includes other application clients as well as other kinds of modules within one ear file. In concrete terms, if you have an ear file containing, say, an application client and a web application, the application client won't have access to classes and resources inside the web application, and vice versa.
• Pruning - The pruning process will be identical to the one proposed for SE and described by Mark Reinhold in this blog entry. The Java EE 6 specification will mark the following technologies as possibly being made optional in a future release: EJB entity beans, JAX-RPC, JAXR. The first two technologies have been effectively replaced by Java Persistence and JAX-WS respectively. The rationale for pruning JAXR is based on its limited use, which doesn't seem to warrant its status as a required component of the platform.
• Content repository for Java (JSR-170) - The Java EE 6 specification will NOT include JSR-170 as a required component.
• JBI (JSR-208, JSR-312) - The Java EE 6 specification will NOT include either of the JBI JSRs as required components.

The following notable issues are currently being discussed by the expert group:

• Best practices around distribution of web applications - In particular, how web applications support customization by the user, either before or after deployment.
• Web profile - Definition and contents of the Web Profile.

Check this blog again in a month for more updates!

GlassFish V2 and Phobos

Once you have installed the new, awesome GlassFish V2 application server, you can download and install Phobos with just a few mouse clicks, using the included updatetool. Upon installation of the Phobos module, you'll find a newly created phobos directory under the root server directory, containing the Phobos framework, the libraries and some sample applications. Each sample comes with an ant script that can be used to build a regular war file, which you can then deploy to GlassFish using the asadmin deploy command.

The version of Phobos available from the GlassFish Update Center is 0.5.11, matching the one available as a set of NetBeans modules.

The first thing you'll notice about this release is that it's quite a bit smaller. This is due to the upgrade to Mozilla Rhino 1.6R7, which implements E4X on top of the DOM API, allowing us to stop shipping XML Beans. This shaves a good 2MB off the download.

Additionally, Rhino 1.6R7 adds support for JavaScript 1.5 language features, such as the const keyword and property get/set methods. See the Rhino documentation for more details.

In Phobos proper, in addition to some bug fixes, the major new functionality we added is an actor library (please refer to the Phobos jsdocs for the details of the API). We also enabled debugging of background threads in NetBeans, so that you can put breakpoints in and step through code executed by an actor.

Clearly inspired by Erlang and Scala, the actor library allows the creation of "actors" in JavaScript, defined as named functions which asynchronously process messages sent to them. Upon reception of a message, the function is executed in a separate thread, so it doesn't have access to the usual request and response objects. Much like Google Gears tasks, actors can only communicate by sending messages to each other or by making changes to shared resources, like a database or (not too often, hopefully) a global variable. Every actor has its own mailbox; messages sent to an actor are processed in strict sequential order. All messages are JSON-encoded, which makes them look like regular objects to JavaScript code.

Overall, it looks like a pleasant programming model for asynchronous activities. There is a lot of functionality which is missing when compared to Erlang, like the ability to pattern-match on messages and to make nested calls to the receive primitive, temporarily changing the behavior of an actor (or process in Erlang terms). On the other hand, much of this functionality can be emulated, albeit less elegantly, using regular JavaScript constructs. In principle, it should be possible to use something like Narrative JavaScript, whose compiler runs fine on Phobos, to compile an actor with nested receives to a "flat" one, but this would required some detailed investigation.

The interesting thing about the model I just described (actors as JavaScript functions, named by strings and exchanging JSON-encoded messages) is that it could be applied cross-tier. It should be possible to implement a similar API on top of Google Gears and have actor proxies on the client forward messages over HTTP to the server. Since actors are identified by a symbolic name and messages are by definition in JSON format, it would be easy to move an actor to a remote location without affecting other code on the same tier. I wonder if anyone has prototyped such a system...

JavaOne D-4

With the 2007 JavaOne Conference four days away, I thought I'd share some session recommendations with my fellow attendees. Since Arun Gupta beat me to it, you should take a good look at his choice of sesssions, which has a large overlap with mine, then take note of a few differences. I bet you don't need me or Arun to tell you to attend Ben Galbraith's Ajax talk (TS-6836) or that other perennial favorite, Josh Bloch's "Effective Java Reloaded" (TS-2689).

This year I've served as the track lead for the Java EE track at JavaOne, so that's where I'll be spending most of my time at the conference. Incidentally, I'd like to thank all the submitters for flooding us with their papers and the review team (including Hani Suleiman as an external reviewer) for their work over the past few months. This is not the place to share tips on how to get your session accepted at the conference, but I can't resist dropping a few ones. The review team is very diverse, we've all attended many conferences over the years and we think we can spot a bad submission at a safe distance. Good submissions are interesting, fresh, well-written, with detailed and convincing outlines, and they include supporting materials in the form of web sites or blogs. We routinely check out the online documentation of any technology we are not familiar with. If you are talking about something new, make it compelling; if it's about a technology that's been around for a while, be thorough and go into some real depth. The abstract needs to communicate that your talk is of consequence to developers: JavaOne is not OOPSLA. Above all, be interesting: given the number of submissions, if nobody on the review team feels strongly that your talk is worth having, ultimately it will be rejected.

In the past few days I've been monitoring the registration numbers and it's clear that the Java Persistence API and Enterprise JavaBeans 3 talks are the main draw, as we expected, so you'll need to register ASAP using the online schedule builder. Two other talks are almost completely filled already: TS-4249 ("The Top 10 Ways to Botch Enterprise Java Technology-Based Application Scalability and Reliability") and TS-1262 ("Killer Apps: Data Mining Demystified"). If you are interested in them, hurry up.

This year we had a smaller allocation of BOFs than in the past, so we created a 2-hour super-BOF for all Java EE technologies. It's listed as two separate events: "Java Platform, Enterprise Edition (Java EE): Meet the Experts (Part 1)" (BOF-4641) and Part 2 (BOF-4612). Although I'm listed as a speaker for both, thankfully you won't have to sit through two hours of elocutions by yours truly; instead, I'll be playing host to a full lineup of specification leads for the different technologies in EE. The plan is to give a short intro to the main components in the platform and then take questions from the audience. So if you want to discuss anything EE-related, from the high-level roadmap to the most minute details of some technology, sign up now, show up at the BOF on Wednesday night at 7:55pm and grab the mike.

As for the other tracks, anyone interested in Phobos should come to the session that Ludovic Champenois and I will share on Thursday at 4:10pm (TS-6957). Since we'll be demoing but not fully describing jMaki, it'd be helpful if you could go to some of the jMaki sessions scheduled well in advance of our talk, e.g. TS-6375 and TS-9516. If you can stay up late (kidding...), there is a BOF on Grizzly on Tuesday at 10pm (BOF-6012) that sheds some light on how we embedded Grizzly in NetBeans to deliver the small-footprint, fast-startup Phobos development-time container. Also, TS-2992 describes in gruesome detail the entrails of the beast (I may have gotten carried away by Jean-Francois Arcand's bear imagery...); anyway, highly recommended to all NIO propeller heads.

Fellow fans of scripting languages will find a lot of content of their liking, ranging from JRuby to Groovy, Jython, PHP, and of course JavaScript on all tiers. If you share with me the excitement about Scala, don't miss Friday's talk (TS-2844) by Scala's creator Martin Odersky. I have taken a sneak peek at the slides and I think they'll blow you away. Also, as part of the CommunityOne event on Monday (which you should attend anyway, it's free, you know?), Charles Nutter has put together a dynamic languages event inside the RedMonk Unconference. Be there!

Phobos at the Web 2.0 Expo

On Wednesday I did a presentation on "Scripting and the Java Platform" at the Web 2.0 Expo in San Francisco. Yesterday I put the slides (PDF) online.

In my talk, I went over three key components: Phobos (the server-side framework and development environment), jMaki (the client side über-framework) and GlassFish v3 (the server platform). I demoed all three of them, and I'm glad to report that, as promised in my slides, the startup time for GlassFish v3 on my Mac Book was well under 1 second (626ms to be exact). Furthermore, deploying a Phobos application took all of 1.3 seconds, and the resulting app was as live and editable on the fly as anything in PHP, Python or Ruby -- if that doesn't impress you, nothing will.

Interestingly, since my session was scheduled on the last day, I got to attend several talks on other web frameworks before presenting. I'd say that the one closer in concept and execution to Phobos is Django. It was great to listen to Django's mastermind, Adrian Holovaty, describe his creation at the conference. I suspect it'd be healthy for the resurgent Jython developers to target Django with the same single-mindedness that the JRuby guys reserve for Rails. Should Jython become Djython?

As it often happens, at the conference I was asked what container Phobos runs on at development time (we sport a sub-2-second startup time there too). Here's the answer: when you run a Phobos application inside NetBeans, it starts a Grizzly-based lightweight web container which does not depend on the servlet machinery. Currently we pretty much gather all the jars that we need and load them together using a child classloader of the NetBeans' one. Of course, since nobody likes maintaining multiple code branches, the plan is to switch to a GlassFish v3-based runtime as soon as possible. An important direction for Phobos from the very beginning was to validate the feasibility of a really small, really fast container. This had the side-effect of offering a convenient target for GlassFish v3: being a new, unencumbered container, Phobos was easy to integrate from the beginning. The fact that the Phobos framework is container-agnostic makes it possible to deliver it as its own lightweight container (where Grizzly does all the heavy lifting) as well as embedded inside a regular web application, which is the mode you'll want to use in deployment until GlassFish v3 ships and perhaps beyond.

If you check out my slides, you'll see that I spent some time describing the notion of "soft" vs "hard" layers in an application, which from my perspective is a key reason for supporting as many languages as possible on the Java platform. Fundamentally, my thesis is that successful platforms, including ones that we normally consider applications, like Office suites, have this distinction between the "hard" layer, accessible to wizards and used to implement the platform itself, and a "soft" layer which ends up being programmable by users (or at least power users). There are more examples of this than I can quote (I listed some of them on my slides), but the interesting thing is that it's hard to come up with good counterexamples, i.e. widely successful platforms which were single-language and didn't enforce a boundary between normal use(r)s and advanced ones. And I say this with all the regret of somebody who, to this day, considers Smalltalk the work of genius.

One slide that seemed to stir the audience was the one where I went out on a limb and singled out one language as having the greatest potential of all on the JVM: Scala. What's not to like? Structural typing, first-class functions, clever integration of object-oriented and functional features, Erlang-like actors, full Java interoperability... On top of it, it gels together like a real language (yes, this is a snipe to a language whose name ends in "oovy"). The rumored addition of record types would make it really perfect; for the uninitiated, in the presence of structural typing record types capture what's become fashionable to call duck typing. In my own classification, Scala falls into the "hard" bucket, but its syntax is light enough to be usable in a larger scope. At any rate, my intent in bringing it up at the Web 2.0 Expo was to point out that there is some awesome innovation happening in and around the Java platform, and developers looking at getting an edge over the competition would be advised to learn about Scala, Phobos, Grizzly, GlassFish v3 and a lot of other Java-related things (Hadoop on Amazon EC2 comes to mind). Did I mention they are all open source?

Running JRuby "servlets" on Phobos

Tim Bray wrote about running servlet-like JRuby scripts inside a web application and I left a comment saying "Phobos can do that". This got me thinking on how to make it easy to get people started in this model.

As always, the best way is to use a running application as a starting point. Once the basic application layout and configuration are in place, all you need is a well-defined place for your scripts and your static files. The starting point is this war file (4.9MB).

To produce it, I started off with the latest Phobos release (0.5.8), created an empty application in NetBeans and generated a web application. The result is a vanilla war file that will run on any servlet container.

In the interest of making the war file more manageable, I then removed all the jars that are not essential, e.g. XMLBeans, JDOM and Rome. They can all be added back easily by dropping them into the WEB-INF/lib directory. I also deleted all the jMaki libraries from the top-level resource directory, since they are unlikely to be used in this scenario. Subsequently, I took the latest JRuby interpreter and its associated JSR-223 scripting engine and dropped them into WEB-INF/lib.

At this point, I got a web application that can run JRuby scripts. If you save a JRuby script, e.g. test.rb, in the WEB-INF/application/script directory, it will be invoked when a request for the /test.rb URL comes in. The script can access the servlet request and response objects using the $request and $response global variables. Here's the inevitable "hello, world!" example:

$response.contentType = 'text/plain'
writer = $response.writer
writer.println 'Hello, world!'
writer.flush

This is far from earth-shattering, of course. What's interesting though is that I did this without writing any code, thanks to the scripting engine pluggability offered by JSR-223. Phobos itself doesn't have any knowledge of JRuby (it finds the right scripting engine to use by looking at the file extension), so I could just as easily have used Groovy by adding the necessary jars to WEB-INF/lib.

Although it all works, I took a few more steps to improve usability. First of all, when accessing the top page of my application, I'd like to run a JRuby script. This is not the default in Phobos, but it's easy to fix: just add one line to WEB-INF/application/startup.js, the Phobos startup script for the application. Here's the line:

application.mapping.rules.push({ url: "/", script: "index.rb" });

This JavaScript snippet adds one more URL mapping rule to Phobos, telling it to dispatch to the index.rb script when a request for the / URL comes in. By default, scripts live inside WEB-INF/application/script, so that's where Phobos will look for the index.rb file.

Finally, it'd be nice, while writing Ruby code, to have access to all the Ruby 1.8 libraries, so I decided to copy them over from my Ruby installation and, to keep things simple, I put them under WEB-INF/classes/ruby/1.8. Once again, I tried to save a few kilobytes by removing obviously unnecessary libraries, like the Tk ones.

Somehow we have to tell JRuby where to look for libraries. I took the easy way out by adding another line to the startup script to set the system property that the JRuby JSR-223 engine uses to configure the JRuby load path. This is not going to scale very well but it makes things simpler. And since I was setting the load path, I also added another entry to it, to allow user libraries to be saved under WEB-INF/classes/rubylib. This way, malicious or overly curious clients won't be able to access them directly.

Here's the resulting code:

java.lang.System.setProperty("com.sun.script.jruby.loadpath", "ruby/1.8" + java.io.File.pathSeparator + "rubylib");

Relative paths are resolved by the application classloader, which includes the WEB-INF/classes component, so I didn't have to repeat it here. From what I know about the way JRuby looks for libraries, it should be possible to add to WEB-INF/lib a single jar file containing all Ruby 1.8 libraries. Even better, it could contain pre-parsed versions of the source files, identified by the .rb.ast.ser extension, resulting in faster library loading.

Now the basic application is ready. I ran the jar tool and created a war file, which I put online here. In order to use it, download and expand it, then deploy it in expanded form onto GlassFish or any other servlet container. (It's going to run as a war too, but then you won't be able to modify it while it's running.) Any JRuby scripts you want to expose to your clients go under WEB-INF/application/script, any JRuby scripts you plan on loading into other scripts using require go under WEB-INF/classes/rubylib and all static files (HTML, CSS, images...) go in the root directory of the web application.

The default URL mapping is very simple, but you can customize it by defining new rules in startup.js (in JavaScript only, alas, until somebody writes a functional JRuby to JavaScript bridge). It's not hard to do things like mapping URLs matching arbitrary regular expressions to a certain JRuby script, or running scripts without requiring the .rb suffix to be part of the request URL. I'll try to add more examples in the future.

Phobos in the Sun Web Developer Pack

We just released the Sun Web Developer Pack and Phobos is one of its components, together with its client-side companion, jMaki, and a lot of other interesting stuff. Arun Gupta has all the details. I recommend checking out the RESTful web services API EA, as a preview of what you can expect from the newly approved JSR-311.

We spent the last few weeks hunting down bugs in Phobos ahead of the pack release, which explains the silence on this blog. In the process, the version number of the NetBeans plugins has gone up to 0.5.6. Now we're back to adding new features, all while supporting our early users. You can find out more about the current status of Phobos by looking at my presentation from the Sun-internal and yet very public jMaki Day event.

It's also conference season. I'll be presenting Phobos at the Web 2.0 Expo in April and then at JavaOne 2007 in May. Stay tuned!

Phobos Plugins 0.5.1 Released

Finally, they are here! You can now download a set of plugins for the NetBeans IDE that comprise the Phobos development enviroment.

This blog entry gives a good introduction to the plugins. Since then, we've been fixing bugs and adding a few features, like better content filtering in the debugger's local variable view. All the key features are visible in the screenshot above: there is a logical view of the Phobos project corresponding to an application; the application is running in-process in debug mode; the debugger has all the expected bells-and-whistles (breakpoints, call stack, variable inspection); the jMaki palette allows dragging and dropping Ajax controls into a view.

There is still quite a bit of work left to do, but the plugins are very usable as-is. A notable missing feature is the "export to war" feature that lets you create a portable war file from a Phobos application. We'll be fixing this in an update to the plugins.

Updates will be pushed to users via an update center that is added to the IDE when you install the 9KB bootstrap plugin. This is shared with jMaki, so you'll always get in-sync versions of the client and server frameworks.

In the meantime, enjoy writing some JavaScript code in an interactive environment and with a fully-featured debugger to help! Check out Ludovic Champenois' screencast for a first look at Phobos.

Phobos Meets Atom, REST

In the Phobos CVS repository you'll now find an implementation of the Atom Publishing Protocol v9. The application name is atomserver. Since we started this work, the APP specification moved up to version 11, so we have some catching up to do, but I thought I'd discuss some interesting aspects of the implementation anyway.

First, it uses some new REST libraries we've been developing. Phobos is a URL-centric framework, so the way you go about designing your application is by defining the kind of URLs you are interested in and attaching logic to them. Typically, URLs map to complete web pages or to AJAX callbacks, but they can really be anything. Fitting REST into this model wasn't very hard.

At startup, the application registers certain URL patterns, e.g. /collection/@id, as belonging to resources. When a request for a resource arrives, the system instantiates a resource object via a factory, then lets it do its job. In the case of a collection, the factory function creates an instance of a CollectionResource class initialized with the id specified in the request URL. So if the request is for /collection/12, the application creates a CollectionResource with an id of 12. The collection id is then used as a key to look up feed information in the database.

The resource base class contains all the boilerplate code to deal with GET and HEAD requests, and all you need to do in a subclass is to return the appropriate representation of the underlying resource, an entity in Phobos/HTTP terms. (Of course, updates and especially POSTs, are going to be more involved.)

Here's a snippet showing the method that creates a collection entity (an Atom feed):

        prototype.getEntity = function() {
            log.trace("atom.CollectionResource.getEntity");
            var info = module.persistence.fetchCollectionInfo(this.id);
            if (info == undefined) {
                return undefined;
            }
            var doc = this.createFeedDocument(info);
            return new library.rest.ConcreteEntity({
                type: "application/atom+xml; charset=utf-8",
                text: doc.toXMLString(),
                lastModified: info.lastUpdated
            });
        }

It's worth emphasizing that there is no controller in the loop: requests are directly handled by resource objects. This is a departure from other frameworks, which route every sort of request via a single controller framework. In Phobos, we decided to model REST directly, by building some new libraries from the ground up to capture the peculiarities of the REST model, rather than retrofitting it in the existing controller framework. Besides simplifying things by shifting more of the work to the framework classes, we hope this will get developers who really want to do REST to think twice before embedding verbs in URLs, e.g. /photo/123456;rotate or /shopping_cart/1234;checkout (I'm referring to this article, by the way).

Another notable aspect of the APP server is the heavy use we make of E4X. I have to admit that, in the beginning, I was very skeptical about it. Somehow, XML and programming languages don't go together very well. I have a theory that the origin of this problem is the dual nature of XML itself, as reflected in its twin uses as document markup (e.g. Docbook) and to represent data structures . Now, after several months of use, I think that E4X is a very powerful tool for processing XML. I'm still not entirely convinced by the syntax, which can sometimes be confusing, e.g. for queries, but it's certainly a big step forward from the DOM API and all its surrogates (DOM4J, JDOM, etc.). You'll find plenty of examples in our Atom server code.

Phobos and NetBeans 5.5

A couple of weeks ago we started showing in public the new set of NetBeans plugins for Phobos: I did a presentation and a demo of Phobos at the Colorado Software Summit conference and Ludovic Champenois demoed the plugins at the Ajax Experience conference. Here I'm going to give you a quick tour of the new features. If you are not familiar with Phobos, I recommend reading the overview document on our web site. We envision these plugins as the way people will write Phobos applications. Of course, you can also do so manually, creating the right directory structure, etc., but as you'll see here, there are some distinct advantages to using an IDE, especially when you are new to the framework.

To start, there is a Phobos application wizard that you can use to create your first Phobos app. Here's a screenshot:

Once the wizard has done its job, you get a Phobos application project with the appropriate logical structure displayed in the "Projects" pane:

The main editor pane is open on a ejs file, i.e. a view. Using the jMaki palette on the right, we drag-and-dropped two controls on the view, a Dojo clock and a Yahoo Map widgets. Thanks to jMaki, there is a uniform interface for widgets, so mixing components from different toolkits is easy.

If you look closely at the toolbar, you'll notice that the application is running in debug mode. To make it easier to test your application, in debug mode we run it inside a test container that runs in the same process as NetBeans. It's not simply a mock container though, because, thanks to the Grizzly HTTP connector, we get a real HTTP server which we can use to serve browser requests. As a result, you can test your application interactively in the browser and make changes to it as it runs:

Any changes you make to any script or view is immediately reflected in the running application. We think that this compilation- and deployment-free approach to building applications really brings the advantages of scripting to the forefront. For deployment, we are working on adding functionality to the plugin to build a regular web application (i.e. a war file) out of your app, so you can deploy it on any application server. We are also going to make it easy to create a web application project that uses Phobos functionality side-by-side with other APIs, like JSP and JSF.

Developing your application interactively is fun, but what if you need to do some real debugging? Isn't JavaScript hard to debug, you may ask? No, all you need are good tools. With a little bit of magic and a lot of work, we wrote a JavaScript debugger for NetBeans that is attached to the scripting engine inside the running server, so you can set breakpoints in your JavaScript code and see what's going on:

As you can see at the bottom of the picture, the call stack pane displays the server-side JavaScript call stack, and the local variables pane lets you inspect JavaScript objects. Since most of the framework code is in JavaScript, you can set breakpoints there too and see exactly how the dispatching logic works. For that matter, you can change that logic while the application is running!

There are many more advantages to using NetBeans to develop Phobos application than I can describe here. For example, you can create a Java library that uses JPA and add it as a dependent to your Phobos project, then use entity objects as the persistence layer for your application. We have some libraries to help you with that too, by the way, more on this another time.

If you can't wait to try this out, Pramod wrote a HOWTO blog entry. Our plan is to iron out a few wrinkles in the plugins, then make them available for download as nbm files and via an update center. In the meantime, all the source code is in our publicly accessible CVS repository, so you can check it out there.

Finally, a call for help: we'd love to have an equivalent set of plugins for Eclipse. Most of the work we did to enable debugging in NetBeans would apply just as well to the Eclipse version, but we need volunteers to do some of the ground work. If you are interested, please send mail to our developer mailing list and we'll take it from there.

Logging in Phobos

Last week we added logging functionality to Phobos. It's an all-JavaScript library clearly inspired by Apache Commons Logging. Although logging is not very glamorous, experienced developers know that it can make a world of difference when chasing down a bug in an application, so it's a much welcome addition to Phobos. I should also point out that this functionality is in CVS but not in the latest Phobos binary build, which is over six weeks old, so you'll have to build Phobos yourself to try it out.

Application logs can be created using the library.log.get function. Here's an example:

  var log = library.log.get("app");

Typically, you'll put this at the top of a module. Here's an example of a controller that uses logging to log an action method:

  library.common.define(controller, "test", function() {
      var log = library.log.get("app");

      this.Test = function() {};

      with (this.Test) {
         prototype.index = function(mapping) {
              log.trace("invoked action: test.index");

              // ... the rest of the action code goes here ...
          }
      }
  });

Just like in Commons Logging, there are six levels: trace, debug, info, warn, error and fatal. For each level, a log object defines a method and a property, with names like trace and traceEnabled. The method is used to write a log entry, while the property is set to true if and only if the corresponding log level is enabled.

Logging is configured via the application.options object. For example, to set the logging level for the app log to debug, you can add the following line to the application/startup.js script:

application.options.log["app"] = {level: library.log.DEBUG};

As you may expect, log names are hierarchical. Moreover, since there is no notion of packages in JavaScript, log names are completely up to the application. For example, you could have a sub-log called app.persistence exclusively dedicated to persistence events, regardless of the script the code resides in.

The Phobos libraries now contain logging code, so you can trace through them with ease. The log name is framework, with sub-logs for each built-in library (e.g. framework.controller, framework.db). This is an excellent way to learn how the libraries work. The debug level is the most appropriate to follow what goes on behind the scenes while processing a request.

As an example, let's see how a request involving a plain script is processed. I took the examples application and added the following line to its application/startup.js file: (the timestamp: false bit turns off timestamping, so the output is easier to read)

application.options.log["framework"] = {level: library.log.DEBUG, timestamp: false};

Then I pointed my browser to http://localhost:8080/examples/hello.js and got the following output:

INFO: lifecyle.onService: GET /examples/hello.js
DEBUG: mapping.applyRules: invoking function: library.mapping.maybeContent
DEBUG: mapping.applyRules: invoking function: library.mapping.maybeScript
DEBUG: mapping.maybeScript: running: /application/script/hello.js
DEBUG: scripting.run: executing: /application/script/hello.js

As you can see, in this (simple) case, the framework started off by looking for some static content called hello.js, then tried to locate a script with the correct name in the script path. It succeeded, finding the application/script/hello.js script, then proceeded to invoke it.

On the Phobos web site you'll find a more detailed document describing how logging works and how you can use it in your applications.

jMaki in Phobos

There's been quite a bit of activity on Project Phobos recently. A notable highlight is that jMaki is now fully integrated with Phobos, ready to serve your AJAX needs.

jMaki offers a uniform interface to an ever-expanding set of AJAX components. When writing JSP and JSF components, jMaki appears as a tag library. For example, this JSP snippet inserts a Yahoo Map widget into the page:

<a:ajax name="yahoo.map"
        args="{centerLat:37.39316,centerLon:-121.947333700,
               mapType:'YAHOO_MAP_SAT', width:600}"/>

Since widgets run in the browser, you won't be surprised in seeing a JavaScript object literal passed as an argument. In the case of a Yahoo Map widget, it contains things like the latitude and longitude of the desired location. Note though that this "object" is enclosed in quotes, as necessary for an HTML attribute.

In Phobos, JavaScript is used on both client and server, and jMaki is exposed via a built-in library, library.jmaki. Here's the Phobos equivalent of the previous code snippet:

<% library.jmaki.insert({component: "yahoo.map",
                         args: {centerLat:37.39316,
                                centerLon:-121.947333700,
                                mapType:'YAHOO_MAP_SAT',
                                width:600}}); %>

As you can see, here the arguments are really an object, not a string, so you can programmatically construct complex arguments with great ease. The jMaki library in Phobos takes care of serializing them to JSON right before inserting their literal representation into the page. And of course, just like the jMaki JSP tag library, library.jmaki.insert takes care of loading all the necessary scripts into the page and instantiating the component, relieving developers from a lot of bookkeeping.

Until recently, Phobos used to package its own version of the Dojo Toolkit, but as a side-effect of the integration with jMaki, it now relies on the version that comes with the latter. This is not entirely pain-free, since existing applications will need to change their references to Dojo to point to the new location, /static/resources/libs/dojo/dojo.js. On the plus side, from now on Phobos will use the latest and greatest (and most tested) version of Dojo as validated by jMaki use. Moreover, Phobos now shares with jMaki a common directory layout for AJAX components and libraries, as well as all the configuration information. This means that a web application can include just one copy of jMaki and use it in a straightforward way from JSP, JSF and Phobos, without any configuration nightmares.

For more information and a quick tutorial on using jMaki with Phobos, see Jennifer's blog entry on the subject. Also, keep an eye on the Phobos web site, as we'll be posting more information there soon.

Tracking JSR-223 Changes

In Mustang b91, the JSR-223 API was updated to fix some issues around the Invocable interface. Sundar's blog entry has all the details.

We updated the Phobos code in CVS to use the new API, but the latest binary build (dated 2006/7/10) predates this change.

The practical consequences for Phobos users are the following:

• To run the 7/10 Phobos build on JDK 1.6 you need a Mustang build earlier than b91.
• If you want to use the latest scripting engines from the scripting project with Phobos, you need to build Phobos from CVS and use Mustang b91 or later.
• The next binary build of Phobos will require Mustang b91 or later.

Finally, this change won't impact anyone running Phobos on JDK 1.5.

New Phobos Build, Plus All The Source Code!

There is a new Phobos build in the documents and files section of our project site. The build is dated July 10, 2006 and is available in binary form for the Solarix/x86, Windows, Linux and Mac OS X platforms.

This build fixes most of the issues I described in my previous post. In particular:

• The E4X extension to JavaScript is fully supported out of the box.
• You can add new scripting engines simply by dropping the necessary files into the glassfish/lib directory. For instance, adding the ability to run Groovy scripts is as easy as going to the scripting project on java.net, building it and then copying the engines/groovy/build/groovy-engine.jar and engines/groovy/lib/groovy-all-1.0-jsr-05.jar to that directory.
• The container now sets the context root automatically, so you don't need any extra code in application/startup.js. The file still needs to be there because it is used by GlassFish to identify Phobos applications as such.

Additionally, it is now possible run a Phobos application on any servlet container by packaging it up as a war file. You can download the war files for our two sample applications from this page. We tested them with GlassFish Milestone 7 and Tomcat 5.5.12. Please let us know if you find any problems with other servlet containers.

Finally, the source code for Phobos and the sample apps has been checked into the java.net CVS repository. As detailed on the getting started page, the GlassFish-specific code is in a branch of the GlassFish CVS repository. Like GlassFish, all the code is under an open source license, the OSI-certified CDDL.

First Phobos Build Available

We made the first Phobos build available on our project site. Just follow the instructions on the getting started page and you should be up and running in no time. In the coming days we'll be adding more documentation, e.g. regarding the application layout, as well as builds for other platforms, like Mac OS X.

In the meantime, here are a few items that could qualify as release notes:

• We are still working through the licensing of some libraries, so you may find that some functionality is missing. The most notable one is E4X.
• The scripting service does not pick up new engines from the classpath yet, so you can only use the built-in ones (JavaScript and JRuby).
• The container does not pass information about the context root to the application, so you need to set that up in the application/startup.js file (refer to the sample apps to see how it is done).
• Phobos applications are not fully integrated with the administration framework. In particular, they do not persist across server shutdowns, so you need to redeploy them each time you stop/restart the server.

Naturally, the biggest caveat is that this is work in progress so expect major changes from one build to the next.

Update: the Mac OS X and Solaris Sparc builds are now available.

A JavaScript Tutorial

If you need to brush up on your JavaScript, this tutorial is a great place to start (link courtesy of reddit).

The caveat on slide 83 about adding properties to Object.prototype resonated with me. Until now in Phobos we've tried to avoid modifying the built-in objects, but there are advantages in doing so, as Prototype shows. You'd think that on the server there'd be less opportunity for conflicts, but what if people start reusing bits and pieces of their favorite client toolkits? See also Joe's blog entry on how the community is self-organizing to deal with the most annoying naming conflict to date ($, of all things).

Why Javascript?

The number one frequently asked question around Project Phobos is: Why JavaScript? Ben Galbraith called the idea of writing your entire application in JavaScript "intriguing", and that's pretty much sums up how we felt when we hit upon it some time ago. Now, with some implementation work under our belt, we've moved it into the "promising" category.

Let's first look at the JavaScript language itself for answers. In the last year and a half, JavaScript has grown in recognition in parallel with AJAX. This has generated demand for good tool support (syntax-aware editors, debuggers, etc.), which is being fulfilled at a rapid pace. Also, some healthy competition among the ever more sophisticated AJAX toolkits has started to fill the most glaring weakness of JavaScript when compared to other scripting languages, i.e. the poverty of its standard library. Finally, the language itself has proven to be usable by mere mortals, at least at a basic level; now the challenge lies with framework implementors (i.e. us) to make sure that as many JavaScript arcana as possible are hidden from a developer's view.

Another set of answers has to do with the JavaScript implementation that we are using, Mozilla Rhino. In our experience, it's a robust, fast, standard-conforming implementation, as testified by the its inclusion in Mustang. Furthermore, a number of Rhino- and Mustang-specific extensions greatly enhance the power of the language, making it possible to implement multiple inheritance, dynamic inheritance, continuations and builder objects a la Groovy. Rhino also supports E4X, further simplifying XML processing. We already use several of these features in Project Phobos and we plan on using them even more extensively as our work progresses.

But I hear you say: isn't the trend in AJAX to completely hide JavaScript from view? After all, that's what RJS and GWT do. Actually, I find it quite remarkable that people would go to such lengths to hide JavaScript, knowing fully well that when the rubber hits the road, in the browser, it's JavaScript that ultimately gets executed. I guess that in the end it'll come down to how good these abstractions are, and whether the illusion that it's really Java or Ruby that you're writing can be mantained to the very end, much like Java tools and debuggers manage to keep the bytecode well out of view. Right now, it seems that the illusion is easily broken when errors (that old scourge of programming) happen, and that the language one gets to use on the server is not quite full Java or full Ruby, since it requires one to follow particular conventions or rules that go beyond the usual ones. By contrast, in the Phobos approach, there is no abstraction, no translation, no hiding anything: it's JavaScript all the way.

This work is licensed under a Creative Commons License.