TheServerSide at JavaOne 2003 - Day 3

Foxtrot framework for Swing/JFC, available at is a great alternative to the many clunky mechanisms for dealing with long operations in a Swing/JFC GUI. See what other alternatives were noticed at JavaOne.

What's surprising at JavaOne?

While standing in line waiting for a session, or having lunch , you might find yourself striking up an interesting discussion with other developers. Here are some examples of conversations that took place about what's really surprising and interesting at JavaOne:

JXTA: "I was really impressed by JXTA. I didn't realize how rich it was... it really seems to be able to enable an agent peer-to-peer system, and it probably could be an interesting platform for Artificial Intelligence-like work. You create agents with a bunch of simple rules and infer a result from something out of their emerging behavior. In one of the JXTA technical sessions, the BBN guys showed a homeland security demonstration for detecting intrusions into a perimeter. JXTA peers would be attached to motion sensors, seisemic sensors, radars, etc. There wasn't a huge configuration nightmare for communication, and JXTA served as a way of reducing the amount of input coming into a system. The peers could collaborate and were able to create a hypothesis about whether something entering a perimeter was a target or not. One agent by itself has outliers and may infer an intruder inaccurately, but a peer to peer system could use heuristics to figure out what was actually going on."

J2SE 1.5 improvements: "It really seems that Sun is pulling out all the stops with J2SE 1.5 improvements, leaving no stone unturned in being reviewed and potentially improved. J2SE 1.5 will probably be the biggest release since 1.2. Let's just hope it isn't as delayed as 1.2 was!"

Foxtrot: One developer at lunch mentioned the Foxtrot framework for Swing/JFC , available at as a great alternative to the many clunky mechanisms for dealing with long operations in a Swing/JFC GUI. The Foxtrot technical session provided a good overview of the code differences between SwingWorker and Foxtrot, with Foxtrot providing easier ways of dealing with exceptions and dealing with a conceptually easier model than the asynchronicity of SwingWorker.

Joshua's Poem and New Java Programming Language Features

Conference attendee's lined up early outside the conference halls for a chance to hear Senior Sun Engineers Joshua Bloch and Neal Gafter give their Abbot and Costello style presentation on the new programming features currently proposed for the Java 1.5 release, codenamed 'Tiger'. These programming language features, aimed at improving "Ease of Development", are designed to clean up some of the messiest and error prone boilerplate code within Java programs. Later Thursday, Borland Chief Scientist Blake Stone gave an excellent follow-on talk describing some of the best practices and gotchas to watch out for involving the new programming languages features.

At the end of the talk, Joshua read out an amusing poem; a satire on the anticipated changes in the Tiger Release:

Tiger, Tiger burning bright
Like a geek who works all night
What new-fangled bit or byte
Could ease the hacker's weary plight?

To the most despised collections' cast
We'll bid a fond farewell at last
With generics' burning spear
The need for cast will disappear

While Iterators have their uses
They sometimes strangle us like nooses
With enhanced-for's deadly ray
Iterator's kept at bay

When from the collections ints are drawn
Wrapper classes make us mourn
When Tiger comes, we'll shed no tears
We'll autobox them in the ears

The int-enum will soon be gone
Like a foe we've known too long.
With typesafe-enum's mighty power
Our foe will bother us no more

And from the constant interface
We shall inherit no disgrace
With static import at our side
Our joy will be unqualified

As for noble metadata
I'll have to sing its praises later
Its uses are so numerous
To give their due, I'd miss the bus

Tiger, Tiger burning bright
Like a geek who works all night
What new-fangled bit or byte
Could ease the hacker's weary plight?

Some of the changes currently being considered for the J2SE 1.5 'Tiger Release' include:

Proposed Changes

  1. Enumerated Types

    • Description- Presently, programmers must use integer constants en lieu of Enumerated types in Java, which has all sorts of drawbacks, not to mention lack of type safety and a meaningful toString() method. Tiger will provide first class support for enumerated types, which will be first class Objects capable of including business methods, data and private constructors, yet will still work within switch statements.

    • Example-
      public enum Suit { clubs, diamonds, hearts, shapes };
      public enum Rank
         deuce(2), three(3), four(4), five(5), six(6), seven(7), eight(8), nine(9),
            ten(10), jack(10), queen(10), king(10), ace(11);
         private int faceValue;
         private Rank(int faceValue)
            this.faceValue = faceValue;
         public int getFaceValue()
            return faceValue;
    • Gotchas- enum is now a reserved word, which could potentially break existing code using it as an identifier.

  2. Generics

    • Description- Casting when using the Java Collections Library is troublesome and error prone. Generics will provide for type-safe collections, eliminating the need for explicit casts.

    • Example-

      public class Card
         private Suit suit;
         private Rank rank;
         public Card (Suit suit, Rank rank)
            this.suit = suit;
            this.rank = rank;
      List<Card> deck = new ArrayList<Card>();
    • Gotchas- In order to support backwards compatibility with existing code, a Collection<String> can be converted to a raw Collection. However doing so will generate compiler warnings as compile time type checking can no longer be guaranteed. If the legacy code inadvertently stores an incompatible type into the Collection, a ClassCastException may result at runtime.

  3. Enhanced for loop ("foreach")

    • Description- Iterating through the items of a Collection is a pain, and the use of iterators use in nested loops can be error-prone. The new foreach style for loop greatly simplifies this code and improves readability. This new looping construct will work for interating through Collections, Arrays, the characters in Strings and StringBuffers, and any Class which implements the new interface java.lang.Iterable.

    • Example-

              deck = new ArrayList
      for (Suit suit : Suit.VALUES)
         for (Rank rank : Rank.VALUES)
            deck.add(new Card(suit, rank));
    • Gotchas-There really aren't any gotchas to this one. However, you may be wondering why the overloaded for construct rather introducing a foreach keyword as is done in other languages. The reason is to maintain backwards compatibility... introducing another keyword risks breaking existing code. Simply read "for (String s: c)" as "for s in c".

  4. Autoboxing

    • Description- The syntax for converting between primitives and their wrapper types has been greatly simplified in favor of making code more readable.

    • Example-

      Integer a = 2;
      int b = (int) a;
    • Gotchas- It's easy to lose track of the boxing and unboxing overhead.

    • Editors Note: You may be wondering why the distinction between int and Integer was preserved in the language at all. Performance isn't the reason, as the code can be optimized at the byte-code level. Neal kindly explained for us that since "==" has different semantic behavior between int and Integer in the present language, changing this could theoretically break backwards compatibility with existing code.

  5. Static imports

    • Description- It's a common anti-pattern for people to implement interfaces in order to import constants into the present namespace. This technique, encouraged in early JDKs, has recently fallen out of favor as it impacts the runtime interface of the class. The static import facility is slated to be added to Tiger to present an attractive alternative to this practice. Classes can now import constants from interfaces and other classes without having to subclass them.

      b) Example-

      static import javax.naming.Context.*;
      Properties settings = new Properties();
      settings.setProperty(PROVIDER_URL, "t3://localhost/");
    • Gotchas- static imports can dramatically reduce readability by hiding the origin of a member. For this reason, this proposed feature is likely to be controversial.

  6. Var-Args

    • Description- Methods which take a variable number of arguments is something that Java presently can't do. There are a few places in the Java API were this could be very useful, such as java.lang.reflect.Method.invoke(...);. Tiger will likely include support for var-args. Don't be surprised to see out.printf(...) in Java 1.5.

    • Example-

      public static void printf(String pattern, Object... arguments);
    • Gotchas- This language feature has the potential to conflict with other overloaded methods.

    • Editors Note: The suggestion of adding printf to Java was actually booed by the audience at Tuesday's technical keynote. Seems like the jury is still out on this one.

  7. Metadata

    • Description- We're familiar with using XDoclet tags to annotate our source code for use in code generation. But these extra annotations aren't available to the reflection runtime, which means the source code must be available any time you wish to do code generation. The new Metadata proposed feature of Java 1.5 seeks to address this issue. You'll be able to annotate classes, fields and methods, and even parameters and local variables. The ability to use Metadata goes way beyond code generation goes way beyond just code generation, as Metadata could be used to replace Deployment Descriptors, the Serializable and Clonable marker interfaces, and the BeanInfo class just to name a few of the potential uses.

    • Example-

      public class @serializable Ping
         public @remote void foo() { }
    • Gotchas-

      1. Overuse of can drastically reduce the readability of the code.
      2. Freezing deployment metadata at compile time can remove deployment time flexibility.
      3. While the Metadata feature will no doubt prove incredibly useful, it has potential to be massively misused. It's presently unclear what all the best practices will be.

  8. Warnings for returns in finally blocks

    • staff approached Neal after the talk inquiring if any changes were in of allowing exceptions or return statements in finally blocks. It turns out that changes are indeed on the way to address this very issue. If you don't know what we're talking about, try running the following code:

      throw new Error("Something really, really bad just happened
      that you want to know about."); } finally { return; }
    • To address this issue the Tiger compiler will generate warnings should it encounter finally statements with returns in them. In fact, addressing this language flaw was considered so urgent that you'll find this new compiler warning feature snuck in the early access release of JDK 1.4.2. Thanks Neal!

    • This little bit of news wasn't in the talk, so you're hearing about it first here on

MDA Case Study

Compuware and The Middleware Company did a presentation describing a study that they had performed to compare the experiences of a team building a J2EE application with Model Driven Architecture (MDA) to that of a team building the same application with a code-centric IDE. The study seemed to be pretty solid and scientific, and the specifications had been reviewed by the Object Management Group (OMG), which creates MDA standards, industry analyst firms such as Giga and Meta, and many J2EE book authors. The architect from The Middleware Company shared his experiences and lots of credible anecdotal experience saying how MDA didn't always solve all their problems, and occasionally it seemed to get in the way, but in the end it did help improve productivity by approximately 35%. This seemed to be just the preview - a detailed white paper on the study is due out later this month.

Technical Sessions

Adding Generics to the Java Platform

This was a similar talk to last year's overview on Generics. Again, it was delivered to a packed house, but also included some new information on why Sun took the approach it did for compatibility purposes.

When instituting a major language change like generics, there are three approaches to compatibility to consider:

  • Language Compatibility- All programs in the existing language remain valid. This is a theoretical notion, and is somewhat useless in practice, because applications are dependent on the platform libraries that potentially take advantage of the new features.

  • Platform Compatibility - All programs that run on the existing platform run on the new platform. Most vendors try to do at least this, and usually by providing two sets of libraries: one that uses the new feature, and one that does not. This is the approach that Microsoft will be taking with .NET 2.0's introduction of Generics. The problem with this approach is that any vendor who wants to migrate to generics will have to duplicate THEIR libraries as well in order to preserve compatibility. All of these dual-stream libraries will lead to difficult to manage cyclic dependencies and maintenance headaches. Everyone must coordinate their migration to the new feature.

  • Migration compatibility - No duplication required, no coordination required, anyone migrates when they want to. Unfortunately this approach constrains the design a great deal. In particular, in Java, the generic system is a compile-type construct, and the runtime type system does not maintain generic type information, so as to retain compatibility with old-style, non-generic code. The .NET Generic approach allows for reification of generic types, hence why they took the Platform Compatibility approach to .NET v2.0.

Using EJB on more projects with CMP, CMR and XDoclet

Rick Hightower gave a talk on the productivity benefits of Enterprise JavaBeans 2.0 Container Managed Persistence (CMP), Container Managed Relationships (CMR), and the XDoclet toolkit. Classic EJB development is often viewed as too complex for smaller projects because of the complex deployment descriptors required to set up the object-relational mapping. XDoclet makes EJB CMP more approachable on small projects.

Rick spent the session giving tutorials of CMP, CMR, EJB QL, and XDoclet, and debunked a lot of the FUD around CMP performance issues.

Container Managed Persistence - Beyond the Spec

A lead developer of Oracle's J2EE implementation gave this illuminating talk on the various issues regarding container managed persistence (CMP) that go beyond the specification: pluggable persistence managers, "concurrency, consistency, and caching" guarantees, and some advanced concerns. He also outlined some forthcoming Oracle features that look extremely interesting.

Developing a pluggable persistence manager (PM) requires a formal contract to be set up between the EJB container and the persistence manager, both at deploy time and at runtime.

He then proceeded to list the many interfaces of how Oracle's 9iAS approaches its contract with other persistence managers, along with detailed interaction diagrams describing both the deployment and runtime contract. It really pulled away a lot of the "magic curtains" surrounding CMP and discussed what effectively has to happen under the covers.

With regards to consistency, there are a variety of options to ensure that updates are not lost: pessimistic locking, optimistic conflict checks, locking at the application server, locking at the database. In a clustered environment, it makes more sense to lock at the database, as most application servers don't have a robust fine-grained distributed lock manager.

Finally, he discussed isolation and the "Commit Options" that determine caching policies. This is a huge deal. Oracle is looking at providing a form of event notification to the application server to notify it of data changes from the database. This will enable application servers to use commit option A for read/write data!

There were a few people lined up at the end to ask questions, but unfortunately someone grabbed the microphone and proceeded to rant for 5 minutes about how Oracle is trying to destroy JDO, preventing anyone else from asking a question. An unfortunate (though amusing) end to a great session.

JAX-RPC Session

The JAX-RPC session covered the expert group's planned support for WS-Security. Client-side security certificates never took off and that leaves Web Services in a difficult situation because PKI/SSL configuration is a huge pain for system managers. The session presented a conceptual view of WS-Security in JAX-RPC. The init() method of an object that is published as a Web Service includes code to identify the client side security certificate, id and password. That means the WS controls certificates for authentication and encryption.

The session also gave more details on Fast Web Services. Sun is working on a binary-encoded remote procedure call that uses SOAP APIs on either end of the connection. Fast Web Services is being proposed through a European telcom standards body. Sun is seeing 5-10x performance improvements over using XML-over-the-wire SOAP calls.

Also covered was support for WS-I. The Oasis Group WS-I specification is a subset of SOAP 1.1 and WSDL 1.1. JAX-RPC will build WS-I code by using a command-line switch while compiling the Web Service code.

BOF-2786: JavaServer Faces Community Input

Faces turned out to be a very popular BoF, and the small room that was allocated quickly filled. The BoF started with a walkthrough of a Faces example, and quickly moved to questions from the audience.

Craig took on one question he had a feeling people would ask. He again talked about the fact that Faces and Struts overlap, so how do they fit together, and what should people be using. His view is that Faces is good technology, and that you should be looking at going into that world... but of course it is up to you.

He has created a Faces-Struts integration library that allows you to use the Faces UI model, with Struts as the Controller. Someone asked if Faces would actually become a de facto standard or not, since there are so many Web app frameworks out there. Craig talked about the fact that prior art always exists before standards come along, and that the only way Faces will become a defacto standard is if it is best of breed... which he thinks will happen.

He was able to "fix his mistakes" from Struts, and when queried on what he thought they were, he just mentioned one major one, that being having the Action class not be seperate from the Form bean. WebWork showed him the light on this, and the WebWork2 architect in the front row said thanks for the plug.

People quickly notice that Faces is lacking in a lot of areas. The struts users asked:

  • "What about the powerful struts validation, can I plug that in?"
          -Craig thought it could be possible to plugin commons-validation

  • "Where is the notion of Tiles / templating?"
          -This will be added in the future via JSTL

  • "Is it easy to change struts tags to Faces tags?"
          -Yes, and he had done that in his integration library

People were also curious at whether the reference implementation was meant to be production quality, or just a showcase. We were told that it was definately meant to be production quality, and something you could suck down and use in the real world.

One of the slides had ugly code for accessing a property from an action:

public Action doFoo() {
 return new Action() {
    public String invoke() {
      ... do your stuff ...

This made people squeemish, and Craig agreed. This will likely change before Faces releases. Thank God!

Something that people were concerned with, was the fact that a form can't be visualised with this technology.

<x:form ...>
 <x:output_text name="..." value="Username:"/>
 <x:input_text name="..." valueRef="logonBean.username"/>
 <x:command_submit ..../>
</x:form ...>

This can't be loaded into a browser and made sense of. Tools HAVE to be used to help out here, unlike a mechanism such as:

<form .....>
 <input type="text" name="username" value="${logonBean.username}">

People have to realise that this is a 1.0 release, so it doesn't have a LOT of things that people really want from their framework.

There is also no way to use JavaScript in your forms. You can't just add onSubmit="" yet. Before 1.0 comes out it will have some more component types like EditableTable, and many refinements.

Someone thought that the renderkits could use templates that had the info on what they spit out for a particular component, instead of having out.println("<input ....") in their code. This way people would have an easy way of changing what comes out of the engine.

Dig Deeper on JSRs and APIs

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.