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
Caplin Systems, creator of the Liberator Comet platform have announced a free version which can be used for non-commercial applications and for evaluation.
Liberator includes a high-performance Comet server, a JavaScript client library, and a Java server integration library.
There are many examples such as the subscriptions sample which shows a page with realtime updating information for a variety of equities and foreign exchange data.
Liferay, authors of a popular open source Java portal, have hired Paul Bakaus lead on jQuery UI to work on it full time.
Liferay’s plans are to standardize all their products to use jQuery and its plugins for the future (you’ll still be able to use other libraries at the same time) - it’s therefore in their very interest to see jQuery UI enjoying a long life, growing to meet expectations of all kinds of clients and beyond. To reach this goal, hiring me was the most logical decision: I now have no excuse not-to-focus on jQuery UI for a while - after all, it’s my day job!
This is good news for jQuery users, especially those that want a better widget framework, and one that looks good a la Ext.
Last week we posted about Jaxer which offers an approach of turtles all the way down where JavaScript is used on the client and the server.
Then, I got to interview Steve Yegge. Last year, Steve posted about Rhino on Rails, his port of Ruby on Rails to the JavaScript language on the Rhino runtime.
What can't you do since JavaScript doesn't have the same meta programming facilities?
Rails = a group of Active*, so did you re-implement everything?
What do you gain out of having JavaScript all the way down?
Does it actually make sense to have jjs? Server side JavaScript generating client side JavaScript? Argh!
What is the state of Rhino?
Will Rhino support JavaScript 2?
And of course, the big questions:
When do I get to see it!
I happen to be in Seattle at the Google offices, so I was able to ask all of these questions and more. Steve was a fantastic host, and I really enjoyed chatting with him.
This is the kind of video I want to explore at Google. We have many great developers working on cool technology. I want to get them on camera, participating with the community when I can. Sometimes we can talk about products and APIs, but sometimes we will talk about fun ideas and projects that we are working on such as Rhino on Rails.
Anyway, give it a watch and let me know what you think:
ExtTLD is using a constructor definition to generate ExtJS code. Every component passes its code to the ancestor's items attribute or other ( data, tools, buttons etc.). Config options are generated from tag's attributes, listeners are generated from the attributes starting ("onX"). In case ID is set by user, global object with this ID is created ( Ext.getCmp("id")) so user can access this object in JavaScript.
WebCream has been renamed and a new version launched as AjaxSwing 2.0, a framework that "does all server communication via asynchronous JavaScript and uses partial page updates to reflect changes in the browser."
New Features
AJAX functionality for component rendering and asynchronous communication with the server
Asynchronous submit of client-side events and operations
Partial page updates only to changed components
Dramatic speed improvements in rendering and request processing
Row context menus in JTable (see TableSupport)
Custom node icons and context menus in JTree (see TreeSupport)
Improved scripts on UNIX platforms
Allow environment variables and directories of JARS in agent.classPath
I had the pleasure of finally meeting Didier Girard. I seem to run across Didier's work every week or so, but for some reason we haven't had a chance to meet face to face, until JavaPolis.
Java and JavaScript share the first four letters of their name, and have an entangled past. Joe Walker has an interesting little take on the evolution of the languages that shows some mirror images such as:
It's interesting that the current simple version of JavaScript already has the features (i.e. closures) that people want to keep out of Java otherwise it will become too complex, and that Java already has some of the features (i.e. classical inheritance) that people want to keep out of JavaScript, otherwise it will become to complex.
And some thoughts on JS2:
With JavaScript, people see a neat, compact language and fear it turning into Java. The good news is that it won't fully turn into Java because JavaScript already has closures and no one thinks they should be taken out ;-) The danger of the "features over complexity" argument, is that it can be applied indiscriminately, creating a monster, and the fear is that JavaScript will become a monster.
I'm gradually coming round to the opinion that many of the changes proposed to JavaScript actually reduce complexity. There are nearly as many frameworks that add classical inheritance to JavaScript as there are Ajax frameworks. Having one solution that we can all agree on can't be a bad thing even if you prefer prototypal inheritance.
Joshua Marinacci, of Sun, has been playing with JavaFX Script. As a way to learn the new language he developed:
Writing this game really taught me the Zen of JavaFX Script (hmm... sounds like a good book title). I often have to fight my procedural Java instincts and instead use binding and triggers wherever possible. It's really a different way of thinking, closer to Lisp or Prolog (and even a bit of SQL), but quite powerful. I'm sure I didn't get it perfect and I bet I could rewrite it in a few more months using a better style, but this is a good start.
So I'd like to share with you my first real JavaFX Script application. It's a simple puzzle game where you click grid cells to turn off the light. As you click each cell the adjacent cells flip as well. You win the game by turning off all lights (hence the name :).
, Showcase
