Ignacio Coloma has announced Loom 1.0 RC 1. Loom is an annotation-based java web framework that includes a ton of new features in this release. After some selective process, these are the bits that could be of most interest for Ajax developers:
Generates HTML 5 markup (with data-* fields), including CSS classes
with the property type.
Based on prototype
An ever-growing list of (progressive-enhancement) web components,
including: multiple file upload, tabs, menus...
Dead-simple javascript validation library with i18n support.
...which mimics the process at the server, in case javascript is disabled.
Just give it a try at the demo. Try introducing invalid input, and check the sources by clicking the "View source" link at the top right of the page. Everything in the demo should work with javascript disabled, including multiple file upload.
The framework also includes a libraries repository which pulls debug/optimized javascript from the google CDN:
And now for something a little bit different on a Friday. Greg Brown from VMWare pointed us to the fruition of nearly a year's worth of R&D: Pivot, a new GUI toolkit for Java.
While traditionally Java Applets and the Web have mixed together about as well as concrete and peanut butter, the upcoming revised Java plug-in might give a window for Java-based GUI toolkits to be of interest to Web folks.
While Pivot's source code is still forthcoming, a quick glance at its classes shows an architecture with a strong resemblance to Java's built-in Swing GUI toolkit, but with many of Swing's rough edges smoothed out. As a long-time Swing developer, I'd characterize it as attempt to create Swing++.
Similarities to Swing include a light-weight rendering model (i.e., it doesn't wrap native components), a nearly identical component contract, a very similar system of UI delegates, and a very similar event model. Differences include a cleaner API (by virtue of nixing direct interoperability with Java's ancient AWT toolkit), different approach to layout, fresh implementations of common GUI components, and a new collections framework (inspired by Java's collections framework but... different).
Thinlet is another, older alternate GUI toolkit for Java that draws its own components and targets Applet developers (though a new version is under development).
Joshua Marinacci has detailed how Java SE 6 update 10 supports the same crossdomain.xml that Flash supports, and how you can marry it with JNLP to allow you to do Applet mashups without permission dialogs.
The applet security model, known as the sandbox, only lets applets connect to the webserver they were loaded from. They cannot connect to anywhere else unless they are signed. Signing is great when you need access to more than what is allowed inside the sandbox, but it has two problems: the user will receive an ugly warning dialog about the applet, and the applet will have full access to the user's computer. Full access is overkill when all you want to do is talk to a webservice on another server. Surely there is some middle ground between the sandbox and full access? Well now there is.
The key is supplying a backwards compatible way of tying to the new JNLP version:
Scott Schiller has updated one of our favourite libraries, SoundManager. Being able to simply play some audio from your Ajax applications can be great, as long as you don't use it gratuitously.... although we tend to do that a little in some of our demos :) We used SoundManager in our Wii Darts application.
The new version has performance improvements so the sound happens a lot quicker, a few bugs are killed, but most of all you will see some really great demos to cover use cases from users such as "I just want to be able to click and play a MP3 link in-page."
Some of the cool new demos:
Page as a playlist: (Muxtape.com-style UI) with a few themes, load/play progress, scrub/seek within track, timing etc.
I got to sit down with Keith Donald and Jeremy Grelle from SpringSource and talk to them about the going-ons on the Web tier. There are a couple of moving parts, from the core Web framework (Spring MVC), to the Spring Webflow controller engine, to the new Spring JS module.
Spring JS abstracts on top of other JavaScript libraries (this release supports Dojo, but more can come), and aims to make certain tasks very easy to do. Jeremy talks about some of the use cases, such as form validation. The library could be used stand alone, but of course there is nice integration with the server side Spring frameworks too. This allows you to annotate in Java, and get nice Ajax behaviour on the client.
Ben and I gave a presentation at JavaOne on what's new with Ajax. Since this was JavaOne, we skewed a little more than we normally would to Java topics, and one of them was using the new Java Plugin, that has great new features such as being able to take a running applet out of the web page, and having it continue to live after shutting down the browser. Java is running out of process here, which also helps the "Java crashing the entire browser" problem.
Anyway, back to our demo. For some context, last year at JavaOne had us performing Guitar Hero on stage, so we knew that we had to use a gaming console in some way. This year it had to be the Wii, but instead of using the console, we decided to just use the controllers.
Wouldn't it be cool to control a Web page using the controllers? We thought so, and we set to it. You can talk to the Wiimotes via Bluetooth, so we needed a stack that would allow us to do just that. Java has a bluetooth stack. We could get an applet to talk to the Java stack. Hmm.
It actually took quite some time to test out the various stacks out there. In the end we went with a native system called Wiiuse that a lot of Wii hackers use. There is a wrapper library called Wiiusej that gave us exactly what we needed.
A quick test later and we had an application that was talking between the remote and the program. It turns out that the main controller sees a series of IR lights that are in the Wii sensor bar, and this allows you to simulate the system with any decent IR source. In the presentation room the big lights that shine on stage were strong enough to act as a sensor bar so we won't even have to use it. We can just point out to the crowd.
Anyway, back to the application. We then wrote a Java class that acts as a state machine for what the remote is doing. It understands the movements, which buttons are pushed, how fast you are moving the device. With this data we could build a simple darts game. With the state machine Java code, and an Applet wrapper that exposed the information, we were ready to get to the Ajax side of the house.
We painted a darts board onto the screen and then had JavaScript start polling the Applet for information via JSObject (As simple as: document.nameofapplet.pollmethod()). This turned out to be more stable than talking the other way, even though it meant we were polling instead of being entirely event driven. When the JavaScript code polled the applet it would pass back a data structure with the data for the coordinates of the remote, and whether the dart had been fired (button A to fire, button B to reload). We would move the dart image on the screen as you move the remote, and when fired we kicked off an animation to fire the dart at the board.
At first, it was all too simple. You setup the shot and it would get the right area every time. Not a fun game. We then decided to add some simple physics to the Ajax game. We took into account the velocity of the throw (if weak it would fall down) and how straight your shot was. If you wiggle around, the dart will not be accurate.
Anyway, this was a lot of fun, and shows that as much as we mock Java applets, if we forget about using them as fancy blink tags, and instead think of them as more extension points, maybe there is life for them.
The video below shows you a demo of the application, the source code with an explanation, and more details.
One of the examples shown is a pretty cool Tetris game:
As Orto simulates the multithreaded nature of Java with yields and timeouts this is of course hard-core simulation (read: hack), but the benefit are that you could Java Games on non-JS devices, like the iPhone.
Orto also seems to try to simulate the Java UI conventions, thus making it easy to convert existing applications (to a certain degree as there is no equivalent in HTML for the richness of Java UIs unless you build them yourself as libraries ike Dojo or Quoxdoo did).
Ethan Nicholas of Sun has posted an article on Java 6 update 10 which just came out in beta to play.
For Java folk there are some huge wins, and for the first time in ages the Java applet has huge changes. If Java Applets can get past the sniggering baggage, there is actually interesting things to see there.
What was the pain again?
Once a Java program is up and running, it's generally smooth sailing.
Modern Java Runtime Environments (JREs) are stable, reliable, and fast.
Unfortunately, getting to the "up and running" part has historically been
more difficult than it should be. Challenges have included:
Difficult to detect JREs, especially from a web browser
Difficult to automatically install new JREs
Large download size
Poor cold start performance
Little overlap between applets and Web Start programs
Java 6u10 was created as a response to these challenges. By carefully
avoiding public API changes, we can get the fixes into your hands sooner --
no need to wait for Java 7!
And the solutions?
Java Kernel
Java Kernel is a new distribution aimed at getting Java software up and running faster. Instead of a full JRE, users download a small installer (the "kernel") which includes the most commonly needed JRE components. Additional components are downloaded as needed, and the JRE will download remaining components in the background and then reassemble itself.
In the current build, the typical download size for Swing programs and Java applets is on the order of 4-5MB, compared to 14.4MB for the full JRE.
Next-Generation Java Plug-In
Java 6u10 includes a brand-new implementation of the Java Plug-in, which is
used by default as long as you are using Firefox 3 or Internet Explorer. The
next-generation plug-in runs applets outside of the browser in one or more
separate processes. Applets still appear inside of the web browser window as
they always have, but this means that it is now possible to use different JRE
versions, command-line arguments, and configurations to run different applets.
The isolation provided by running the web browser and the JRE -- two very large,
very complex pieces of software -- in separate process spaces improves the
reliability of both, and gives applets the same flexibility and control over JRE
configurations that other Java software has always enjoyed.
Since applets now feature the same powerful JRE selection and configuration
that Java Web Start programs do, it was only natural to use the same mechanism
for both. The Java Plug-In now supports using Java
Network Launching Protocol (JNLP) files to specify applet configuration and
startup options. With very little additional work, you can now deploy the same
program as both an applet and a Web Start program, and still take advantage of
JNLP services such as PersistanceService and
FileSaveService.
New Plug-In Advantages:
Improved reliability
Improved JavaScript communication
Per-applet control of JRE command-line arguments
Per-applet control of JRE memory settings, larger maximum heaps
JNLP support
Per-applet JRE version selection
Improved Vista support
Much more information about the new plug-in can be found in the release notes.
Also note, that with this version you can take a running Applet in the browser, pull it OUT of the page, close the browser, and see the applet still running (since it runs in a different process). This is very cool indeed.
Add to all of this the easy bridge between Java and JavaScript, and there are interesting opportunities.
The main idea behind GChart is simple: You can make very nice charts efficiently out of a reasonably small number of 1-cell Grids (for the aligned labels) and (empty) Images (for everything else), styled and positioned appropriately on an AbsolutePanel. Not surprisingly, bar charts don't suffer at all under the limitations imposed by this strategy--but (as long as you don't mind using dotted connecting lines or banded-filled pie slices) line and pie charts also do remarkably well.
With version 2.0 the library adds support for pie, line, and area charts, baseline-based bar charts, and more.
Reading this, you may wonder how I ended up implementing pie slices
and arbitrary angled connecting lines. Did I use the "transparent
border triangle trick" and/or clever algorithms from walterzorn.com?
Though I tried to use these, I reverted to something a lot simpler:
dotted connecting lines and banded-filled pie slices. Two new Symbol
class properties, fillSpacing and fillThickness, let you control the
spacing of the dots/bands and their size/thickness.
Though this approach means you may sometimes have to choose between
visual chart quality and speed, these new properties make it easy for
you to control this tradeoff. Besides, I like to think that dotted
connecting lines and banded fill pie slices really don't look all that
much worse than the solid fill variety. But then again, I could never
understand why no one ever used square pie charts...
In any case, the whole point of GChart is to layer the chart on top of
standard GWT Widgets, so, since those Widgets can only really draw
rectangles efficiently, I decided to make a virtue of necessity and
whole-heartedly embrace this dotted/banded look.
CSS Convenience Methods: A cure for "CSS anxiety disorder"?
For many months I suffered from "CSS anxiety disorder": a condition
arising from one's desire to use CSS to specify an attribute (and thus
conform to a GWT best practice) while simultaneously wanting the same
property in the Java API (so that it would not be unnaturally
segregated from closely related features).
To address this (possibly imaginary) problem, the GChart 2.0 Java API
includes "CSS convenience methods" that can (optionally) override
traditionally CSS-based attribute specifications for certain selected
CSS attributes.
To some, this may seem like a fine point, since you could easily do
the same thing via a GWT DOM class method call, but to me, once you
invoke a DOM method you are thinking of the GChart as an HTML element,
and for some usage scenarios, that just isn't logical.
For example, for some applications, the background color of a GChart
is mainly about how the color-scheme of the chart blends in with the
surrounding page, and for these applications a CSS-based specification
makes good sense. Yet, for other applications, it is mainly all about
how well background color matches with, say, with the pie slice
shading pattern. That is, in some cases, background color is better
viewed as a feature of the GChart considered as a Java object
independent of its connection to any web page. So why can't you just
call GChart.setBackgroundColor in such cases? With GChart, you can.
To assure that the two specification methods can exist harmoniously
together, GChart recognizes a special property value, GChart.USE_CSS,
which instructs GChart to stand aside and allow the traditional CSS
cascade to define the attribute. For all such "dual access" GChart
Java properties (which are simultaneously also CSS attributes),
USE_CSS is the default property value. This assures that you can use
CSS just as you would with a standard GWT Widget whenever it makes
more sense to control that attribute from the "GChart as HTML element"
perspective.
Thanks to these CSS convenience methods, I have attained inner peace
through Java/CSS redundancy. I recommend the same treatment for anyone
else suffering from "CSS anxiety disorder". See the GChart.USE_CSS
javadoc comment for more information.
I am sure that John will be porting this to the GWT for JavaScript 2 at some point soon!
Client-side Echo applications do not require an application server, and can also be run entirely offline.
With Echo3, the formerly server-side-only component framework has been recreated in client-side JavaScript. This was not a direct “portâ€, but rather a re-imagining of the framework with the ideals of JavaScript development in mind. For example, the client-side version of the framework takes advantage of JavaScript's object and array literal syntaxes to create a capability called "hierarchal component construction", where an entire hierarchy of components can be created in a single call. Such code winds up being extremely readable, as, when naturally indented, it resembles the component tree.
Core.js framework
A low-level framework, called “Core.js†was created to ease development of object-oriented and event-driven code in JavaScript. Core.js provides an inheritance model for building JavaScript objects using class-based (rather than prototype-based) inheritance. It additionally offers the capability to specify abstract classes and methods, and features “pseudo-private variables†where a class can reserve internal method/field names that cannot be overridden by subclasses. The framework includes utilities for managing events and listeners, and can register event
handlers on object instances.
New Back-End / Rendering APIs
The “back-end,†which is responsible for rendering components within the web browser, has been re-engineered for Echo3. Instead of each component having its own client-server serialization code, Echo3's web application container simply serializes the state of updated components directly to the client, where JavaScript versions of the server-side components are then created and updated. This feature makes the component development process substantially easier and faster than it was in Echo2. The new approach also yields performance dividends when creating server-side Java applications -- Echo3 consumes less CPU and a mere fraction of the bandwidth of Echo2.
New and Improved Components
Many new components have been added to the framework and existing components have been enhanced in Echo3. WindowPanes, for example, will always stay on screen, even if the browser window or containing component is resized. Menus can be configured with opacity and fade-in effects. New components have been added to the Extras library including a RichTextArea and Tree/TableTree. New APIs for keyboard accessibility and focus management allow for mouse-less operation (note: still under development in some components).
Joe Walker tipped me off to a preview of iWebMvc which is meta framework that ties together DWR, Dojo, Spring and Hibernate/JPA a la AppFuse or Grails.
It is created by Jose Noheda, a DWR commiter, and the project aims are:
Is based on Java
Although supporting Grooy / JRuby is a plus
Helps me to kick start a project
But simplifying the process by giving me the best (and this can be tricky) set of frameworks for each task
Integrates both server and client sides
And it's lightweight, robust and extensible. Read enterprise quality.
Supports all the common tasks a web app has to handle
I include here: User Management, CRUD operations, i18n support (both framework & data), AJAX and astounding visuals
