Janice J. Heiss's Blog

Community: Java Patterns Archives

Where the Software Met the Road

It's day two of JavaOne '06, and I’m over at the Slot Car Racing Programming Challenge area, where the track is heating up. Developers are standing in line, some for the 20th or 30th time! to see if their latest tweaks will pan out as they hoped. A lot has been happening here. The ABC Morning News guys were here with their cameras. Developers are taken with the chance of being onstage with James Gosling and spending some time with him. Gosling himself has been trying out the slot cars off and on for a few days. Some contestants admit that the slot car race brings them back to their childhood. Developer aren’t exactly closet game junkies.

I approach one, who asked to be referred to as “Turtle,” and ask him if this is harder than he expected.

“It’s very difficult,” says Turtle. (Yes, the name gives away something about his times.) “I have no experience with real-time. There is a lot of tuning, a lot of unknown variables – every car runs a little different. So even if you tweak it right for one car, it may not work for the next. This is about my 15th attempt and I’ve missed two sessions already.” (I’m beginning to understand why he doesn’t want his real name used.) “I’m getting better each time, and finally made it into turn three.”

When I ask him how this is affecting him he says he wants to build a race track in his home. “This is a lot of fun. Once your car runs, the times are posted for your machine and you can figure out how fast your car is going at each sensor point. You could copy and paste this if you wanted, but it would be preferable if they gave you all of your races together so you could analyze all of the numbers.”

Turtle informs me that the man standing next to him is tied for the lead. His name is Peter Whitfield.

“I’m probably the worst Java programmer here – I’m more of a manager than a programmer,” admits Whitfield. “It will be embarrassing if anyone looks at my code. I have no experience with real-time Java, though 20 years ago, I worked with real-time systems. This is a lot of fun and a good opportunity to see how the real-time Java stuff works. It’s easy.” Different strokes for different folks.

Peter -- who is quite generous with his time as he keeps eyeing the monitor above the track listing the names of who's in the lead along with who is currently racing -- completed the race in 25.49 seconds somewhere around his 20th trial and estimates that maybe 10 or 12 people out of 100 have made it to the finish line without crashing. Clearly the hardest thing is just making it around the track. I ask him the secret to his success.

“Keep it simple -- do the absolute minimum necessary to get the result,” Whitfield explains. “There are guys doing some very sophisticated algorithms but I have not actually modified the sample algorithm at all, I’ve just been changing the parameters. Nothing in this application has been hard. I have an engineering background rather than a pure software development background and this is about manipulating voltages to control the speed, and that’s second nature to me. So my background helps. I have only now started changing the way the real-time stuff works. Until now, I’ve only changed the parameters of the way the speed changes as it goes around the track, so a lot if it involves trying to figure out how, if I change the voltage in one place, it affects the speed in another. That’s what people are missing -- they don’t understand how if they go too fast in one part of the track, it will make the car unstable later. The Java side of it is very easy to pick up because we are given a sample program. We have not had to set up the framework for it. Real-time programming is about understanding physical systems; it's not as abstract as writing UI software. So you need to understand the physics of what you are trying to do and the timing.”

I ask if he spends a lot of time visually contemplating the track. “Absolutely – I stare at the track trying to understand where things happen. It’s a spatial thing and physical thing. I can run the same program 10 times and get different results each time. There are 5 different cars that all perform differently. We don’t know which car they will run, so we can’t tune it for a specific car. The challenge is to write software that is in tune with the reality of what you are trying to make happen.”

Peter went on to say: “I learned that I don’t program in Java often enough, so I hope people aren’t looking over my shoulder when I look up Google to figure out how I do multi-dimensional arrays. You need to be aware of where you are putting your thread to sleep and where it will wake up and if you are doing it in more than one place you need to think of the different permutations and where it can all happen.”

And what else is Peter doing at JavaOne?.. “I’ve spent way too much time here. I don’t have a boss so I can sit here and just have fun.”

I talk to a few other contestants waiting their turn. Jonathan O’Keefe, who does database programming, is trying out real-time for the first time. And there is Ulrich from Denmark who does web applications and GUI stuff and business logic, and Michael from Germany who does desktop programming and Carl, an American, from a company called Triego Network Security, who manages security information. None have experience with real-time. The line ebbs and flows at various times, but there's always someone racing, and there are a lot folks sitting in front of the machines set up for them on which they work on their real-time programs.

Only Carl admits to big ambitions. “At first,” says Carl, “I was over-complicating it by treating it like a J2ME product, but if you are very conservative about the objects you allocate, you can treat it as a regular Java program. You have to keep it simple and not allocate anything in the loop or you will run out of memory. I’m going to try to knock someone off the leader board -- I’ve just started with the base program so there is a lot of room for improvement.”

Carl sees uses for real-time Java at his company, Triego. “We do some close to real-time work and try hard to keep our GC under control and use a concurrent generational collector, so the real-time Java technology is very interesting. We could find a lot of use for this technology in the work we do. It’s interesting and the applicability of the predictability of execution time is great.”

As I walk away, I see that Robert Chu is tied with Peter Whitfield’s 25.49 seconds time while Richard Yee is third, at 26.18, and Rivera (I don't catch his first name) is fourth at 28.60. I wonder if any of these folks will be in the top three when James Gosling gives his keynote on Friday morning. Time and times will tell.

Stay tuned. The winners will be announced and compete one final time at the Gosling keynote on Friday. Should be a lotta fun!

Finally, here's a story about the Slot Car Racing Programming Challenge yours truly wrote over on java.sun.com:

The 2006 JavaOne Conference Slot Car Racing Programming Challenge
http://java.sun.com/javaone/sf/slot_car.jsp

And, in the form of shameless self-promotion, here's an interview that I did not far back with Sun Distinguished Engineer, Greg Bollella, on real-time Java:

Programming in Real-Time Specification for Java (RTSJ): A Conversation with Distinguished Engineer Greg Bollella
http://java.sun.com/developer/technicalArticles/Interviews/Bollella_qa2.html

RTSJ and the JavaOne Slot Car Challenge

Conscientious Software

Exposing Java Technology Performance Myths

Here I am at TS-3268, "Java Technology Performance Myths Exposed," with Cliff Click, of Azul Systems. Azul, founded in 2001, advertises itself as pioneering "the industry's first network attached processing solution, designed to unbound compute resources for virtual machine based applications. Without any application level modifications, binary compatibility requirements or operating system dependencies, this fundamentally new approach eliminates the need to capacity plan at the application level and dramatically lowers the cost and complexity associated with the traditional delivery of computing resources."

Click enumerated six performance myths. What follows are the basics.

Myth One: The notion that you can add the "final" key word and your code will run faster. The assumption is that by adding the "final" key word I allow the JVM to inline and do the right thing. Not true. "Final" won't make your code run faster.

Myth Two: Try/catch blocks are free or they're very expensive. Google gives both bits of advice - that it was free or kills performance. Both are wrong. It is both very cheap and very expensive - depending. Advice: Don't put try/catches in very tight array loops. Otherwise it's more or less free.

Myth Three: Use RTTI - Run-Time Type Info. Compared RTTI versus instance-of if-tree versus virtual call. RTTI makes for really ugly code - it is fast though, so only use it if you're desperate for that last bit of performance.

Myth Four: Synchronization is very expensive. The truth is synchronization is not free, but it's no longer so expensive. It's gotten a lot cheaper over the years.

Myth Five: Object pooling works. The idea is that we can reuse objects by pooling them on and off free lists instead of using new and letting the garbage collector pick them up. Once you have more than one thread going off the pool, you need a synchronized free list, which has costs. If the list gets hot and contended, you can get scaling bugs. It gets complicated too fast and is not worth it for small to even moderate sized objects. Use it only for large objects.

Myth Six: The cost of the revisions to Java Platform Standard Edition 5.0 are substantial. Not true. Enums, autoboxing and varargs are mostly free.

Cliff wrapped up his session with a few final observations:

GC is getting cheaper and pretty efficient, and less intrusive. There are still scaling problems with large heaps.

Object pooling will remain viable for largest objects with high costs. Small objects will get even cheaper.

Click closed with one piece of advice: "If you take away only one thing from his talk, it would be that modern JVMs favor common usage patterns and clean code."

Project Looking Glass: An Expanding Universe on Your Desktop

I'm at TS-7992 where Project Looking Glass (LG3D), a Java technology-based open source project that brings a richer user experience to the desktop through 3D windowing and visualization capabilities, is being presented to an audience of, I guesstimate, 800 people. LG3D sprang from the very creative heart and mind of Sun's Hideya Kawahara. Recognizing that desktops had not changed substantially in 20 years, he set out to make them more aesthetically appealing and powerful. Operating on the assumption that the next user interfaces would be 3D, he initiated a side project that would consume at least two hours a day of his spare time, plus most of his weekends and holidays for more than a year before taking hold at Sun. To put it mildly, it has taken hold. It's the most popular "app" on java.net (http://lg3d.dev.java.net) with 26,600 source code downloads, plus 600 members (and counting) since the 2004 JavaOne Conference where it was open sourced.

So what's the latest? Hideya and Paul Byrne, LG3D project owners, demo'ed a range of 3D images, a music player, scenes in which you could alter the backgrounds with a click, "Alice" an award winning 3D media player (http://alice.dev.java.net) that is the first to utilize the 3D capacity of Looking Glass, and more.

CosmoSchedulerD, a three-dimensional application running on LG3D software, created by developers at the Kyushu Institute of Technology in Japan, won a Duke's Choice Award (http://java.sun.com/javaone/sf/dukes_choice_awards.jsp). As a schedule book, it recreates outer space, with your personal solar system built in by arranging the planets according to their dates. The front of the orbit represents the current time, while the size of the planet symbolizes an appointment's importance, which makes it hard to forget an event even a few light years from now. CosmoSchedulerD contains features that ordinary schedule notebooks don't have, such as automatic scheduling, networking, and a workspace manager. Imaginative desktops seem to inspire even more imaginative apps to be built on them.

(I can't escape the feeling that talking about innovations on a gorgeous 3D desktop is like a donkey carrying a load of books. Have to shake it off. By all means go check out "Philco" running LG3D, the mock-up on the cell phone, and LG3D on a 3D LCD display, and all the rest on the pavilion floor!)

Hideya and Paul gave a brief summary of how to create a "deep" 3D environment. It's built on Java 3D with specialized classes that include a component model, animation system and SceneManager interaction. The LG3D 0.7 release has just arrived. There is now WebStart support (http://lg3d-webstart.dev.java.net) for running the "developers" mode of Looking Glass. It operates in application mode so LG3D can run on top of a user's existing desktop. Java 3D 1.4 now enables performance improvements like shader support. It has Open Solaris support.

In the pipeline is tool integration, a visualization library, and "SwingNode" support. There will be greater inclusion of identity and collaboration features and a more task-oriented UI.

To run it: http://lg3d-webstart.deve.java.net

To get it: http//lg3d-core.dev.java.net

To learn more about LG3D: http://java.sun.com/developer/technicalArticles/javaopensource/plg .html

http://java.sun.com/developer/technicalArticles/J2SE/Desktop/look ingglass/

A Pragmatic Application of SOA (Service-Oriented Architecture)

Over at TS-1640 Pragmatic SOA: A Case Study, with developers Ashok Mollin, Ashesh Badani of Sun Microsystems, Inc. and T.N. Subramaniam, Director of Technology at RouteOne LLC Inc. Ed Ort (http://weblogs.java.net/blog/edort/archive/2005/06/pragmatic_soa.html) and Tim Bray (http://www.tbray.org/ongoing/) of Sun are blogging the session in greater detail. I will be doing a story on this for java.sun.com in a month or two so stay tuned. For now, a sneak preview.

RouteOne provides a web-based Credit Aggregation Management System (CAMS) created to accelerate the automotive finance process for dealers and their finance sources. The session presented “a real-world implementation of an SOA project at RouteOne LLC and helps explain the architecture and various best practices, design patterns, standards, and technologies involved in building an end-to-end business solution.” The presenters define Service Oriented Architecture (SOA) as “an integrated software infrastructure and design approach, leveraging Web computing standards, for delivering business functions as shared and reusable services.”

A lot of people regard SOA as a real challenge, in part because it typically involves both substantial organizational change, in addition to new ways of organizing IT. It seems like a situation in which developers have to be, not only technically sharp, but good listeners who can understand the culture of the company they are working with. Creating a shared service requires technical design prowess — architects have to know who, when, and where in the business process, services will be consumed. And then there is the whole history of ERP enterprise resource planning, in which some CIOs and IT managers experienced a lot of growing pain involving expensive projects that required changing processes across the enterprise as part of automation. It has not always worked out. Some people fear that SOA will bring a lot of pain to companies because it may be bigger than an ERP implementation. So businesses are sometimes understandably cautious. There can be a lot to rethink: development methodology, business impact, infrastructure, budget, organizational design and more.

Another challenge involves creating high-level business components that can be re-used and re-configured. One problem is that the requirements that yielded the original component interface were different enough from the new ones so that they required the re-write of substantial functionality.

The basic approach of Sun’s Ashok Mollin and Ashesh Badani, along with RouteOne’s T.N. Subramaniam, seems sensible and cautious: Projects need to generate ROI in 12-18 months so start small and be opportunistic. Minimize disruption to existing infrastructure; reduce risk with fewer web services initially while climbing the skill curve. Wrap legacy/existing applications using adapters + WS; Java and .NET interoperability. Evolve into a flexible, standardized architecture; does not mean “rip and replace”. Foster cultural change to encourage reuse. Take a top down approach – let the business drive!

They addressed several critical problems:

Single Sign On

Transparent login from lender portal

Get Dealer Information

Accessing volatile dealer information at runtime

Import Credit Application

Start the process on another system – DSP

Orchestration

Maintain state and coordinate document exchange in long running transactions with Lender

A summary of their “Pragmatic SOA wisdom:

Start simple, don’t let the “alphabet SOAup” overwhelm you.

Let business identify the service.

Think XML documents not objects.

Use SOAP as an envelope, but not for binding.

Use WDSL 2.0 for description not code generation.

Think asynchronous conversations.

Use WSBPEL to orchestrate the process.

Use JBI for integration.

Keep learning, this is not finished.

Question as I left: Did the large Java developer audience there come away enthusiastic about SOA? There certainly were a lot of smart, probing questions in the brief, casual q &a after this session, if that's any sign.

This work is licensed under a Creative Commons License.