sorted by: recent | see : popular

Content Tagged with front + Java

Dave Kuhn has put together a comprehensive guide to piecing together GWT and Spring, a nice recipe for the Java heads among you.

Dave starts out by detailing why you would want to do this, and how it changes the architecture of your application.

He then gets to a tutorial that has you creating the project correctly, and configuring an actual service. Once you are done with the code, you need to setup hosted mode to point to a nice external tom cat via:

-out www GwtWisdom/GwtWisdom.html
-noserver
-port 8080

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).

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.
• Play MP3s in-place demo.

Download the latest library.

Oh, and you gotta love the Web 2.0 and Web 3.0 explanations of SoundManager ;)

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.

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.

Java Deployment Toolkit

The Java Deployment Toolkit makes deploying Java applets or Java Web Start
programs a snap. The Deployment
Toolkit JavaScript file provides:

• Accurate detection of installed JREs
• Seamless JRE installation
• Complete applet launching (JRE detection and, if necessary, upgrading)
  in a single line of code
• Complete Web Start program launching in a single line of code

The following HTML code is all it takes to ensure that Java 1.6 is installed and
then a Java applet is launched:

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.

Echo has been known as a Java server side component framework, but with the release of Echo 3, they have added a way to build component applications using JavaScript:

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).

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.

This is how a subscriber looks in JavaScript:

Cross posted from my personal blog

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.

Ever since he presented on the 'Google Rails Clone' at FooCamp and he posted about the internal Google Rhino on Rails project, people have been curious to learn more.

• What does it mean to port Rails to JavaScript?
• 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:

This also lead me to the fun idea of Java and JavaScript flip-flopping:

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
• Drop shadows are added to windows

Fancy writing your apps in Swing? If so, check out the demos, and download away.

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 :).

You can download the code and take a peak at the new language: