Skip navigation
ANNOUNCEMENT: community.oracle.com is currently Read only due to planned upgrade until 29-Sep-2020 9:30 AM Pacific Time. Any changes made during Read only mode will be lost and will need to be re-entered when the application is back read/write.

I have been at JavaOne since 1996, its inaugural year. In 1996, JavaOne was colocated with the Software Development conference, which has since fallen on hard times and vanished. But at the time, half of the exhibitors were from SD, and the other half from JavaOne. Weirdly enough, the JavaOne booths were all yellow with a bit of red and blue, so it looked as if the SD half of the exhibit hall represented the free world and the Java One half a totalitarian regime. This year, JavaOne is again colocated with another conference, Oracle OpenWorld, but I am on sabbatical in Vietnam, so I didn't get to enjoy the show.

However, through the miracle of the blogosphere, it is amazing how much information one can get without actually being present. In fact, maybe it's helpful to be outside the reality distortion field. Here is my take from afar.

1. As already hinted, Java SE 7 will have modest improvements and be delivered in 2011. Java SE 8 is promised for 2012.

2. I didn't hear anything about Java EE 7, but that's ok—the EE 6 app servers are just rolling out.

3. There were encouraging words about commitment to GlassFish and NetBeans.

3. The big surprise announcement is Java FX 2.0. A release is promised in 2011 with an ambitious roadmap. There will be Java bindings to the API, which means you no longer have to use FX Script. Now that's something that I have asked for ever since I first heard of Java FX. (By the way, FX Script will not be developed further.) Also promised are a rewrite of the media stack, a new accelerated graphics stack called Prism that works outside the AWT, and a mechanism for rendering a scenegraph to HTML 5. All of this has been touted as “Swing 2.0”.

I am baffled by this, in particular, the timeline. We were told that it would take until mid-2012to deliver the originally planned Java SE 7. Fair enough, but how can Java FX 2.0, which seems at least as ambitious, come out so much more quickly? Someone still has to work out some pretty basic details, such as how bindingis going to be done in a Java API. Multimedia has not been a strong point of Java FX in the past; see for example this blog to get a feel for some of the issues. Prism sounds great, but it's not something for which I could find any public information. And I don't begin to understand the HTML 5 angle. Every time that I hear “rendering for multiple display technologies", I run for the hills. Remember Java FX Mobile? (By the way, that's now dead too.)

I very much want to see a modern client-side library for Java, and if Amy Fowler says that Swing isn't going to cut it, I'll look forward to Java FX 2.0. Provided, of course, it is available under GPL and, at least as of SE 8, a part of the platform. But I am not getting the warm and fuzzy feeling that this is going to happen without pain, or by 2011.

4. I was equally baffled by the mobile announcements. The quote that stuck in my mind was from Thomas Kurian: “I would not underestimate our capability [of] delivering a new Java platform [in this space]”.

Ok, count me among the under-estimators.

Yes, I get the point that there are 10x more feature phones than smart phones. I have one of them. But I am not running a single Java app on it. I wouldn't even know how to get one. (I tried once and was hit with some outrageous data charge—thanks, Verizon.)

A while ago, I used a Blackberry. It had a bunch of fine apps, but those weren't Java ME. Ok, not true. There was one Java ME app that I ran—a terminal emulator. Very mainstream...

Right now, I use an Android. It has a bunch of great apps, but they aren't Java ME either. In fact, I understand that Oracle has issues with that platform...

I realize that elsewhere in the world, people do use Java ME apps, but it really seems like fighting yesterday's battle. And if I did want to fight yesterday's battle, I would promise to give feature phones the good 90% of what smartphone users enjoy—apps that integrate with the calendar, messaging, maps, and media on their phone (and, for that matter, Java-based calendar, messaging, mapping, and media for those phones that don't have them—like that feature phone that I no longer use since I got the Android.) I don't see how talking about WebKit, a Java-to-JavaScript bridge, and LWUIT is going to keep mobile Java alive. (And no, I didn't understand where WebKit comes into the picture.)

So, here is what I conclude, from my vantage point as the Sage of Saigon:

  • Java SE 7 and 8 will be delivered pretty much as planned
  • GlassFish and NetBeans will stay viable choices for developers, at least in the near term
  • Something called Java FX 2.0 will materialize, but it will be late, not have all promised features, and not be Swing 2.0. Eventually some viable Swing replacement will emerge from the good parts. In the meantime, Swing will be left to wither on the vine, and it will be a challenging time for Java desktop developers until the dust settles.
  • Java ME will continue to lag behind developer expectations

If I am wrong, I will really need to attend Java One 2011 to get a better reading of what is happening.

Stephen Colebourne has a very interesting article on the Next Big JVM Language (NBJL). The comments are good too. (I was going to add this as a comment to his blog, but it was rejected as spam. Maybe jroller is onto something...)

Stephen defines the NBJL as a language that targets the JVM and is broadly adopted, i.e. the dominant language on the JVM. He argues that such a language must (a) fix the flaws in Java that are now obvious and (b) be useful and comprehensible to the "typical developer". In his opinion, this rules out Clojure (too Lispy), Groovy (too slow), Scala (too complex), and Fantom (type system too weak). He argues that the NBJL should be Java, or rather, a backwards-incompatible version of Java with the cruft removed and a relatively modest set of improvements. Which, at the speed things are moving, should be ready right around the year 2525. If man is still alive.

Just kidding. I can see his point. But I don't think it's going to happen.

The blog comments were mostly about Scala. It's too complex! It's not! It is too! Not!

So, it seems as if Scala has become the NJL to beat, and the question is whether it can become the NBJL.

A sweet spot of Java has been it's "blue collar" nature. A working programmer could understand all aspects of the language. Contrast this with the byzantine complexity of C++ whose users at some point simply must declare their faith in the library designers and hope for the best.

At least, Java 1.0 had that ideal "blue collar" nature. Post-1.0, not so much. I have met plenty of programmers who didn't understand inner classes, serialization, reflection, or, of course, generics. Ok, make that Java 1.0 minus monitors--lots of working programmers don't understand those either. In fact, I'd add to Steve's list of features that the NBJL must have: "Blue collar concurrency".

Creating a "blue collar" language isn't something that happens every day.

When done by "blue collar" people who have sketchy knowledge of programming language theory, the result is often problematic. Look at PHP--I trust that I won't have to elaborate... Or Groovy, many of whose properties (particularly in the MOP) are under-specified and constantly shifting.

Few "white collar" people have an interest in designing a blue-collar language. They give us languages that dazzle us with their brilliance and innovation. After all, that's what a researcher is rewarded for.

As white collar languages go, Scala is better than most. Much attention is paid to compatibility with the JVM, the Java libraries, and the Java tools infrastructure. This isn't the "just shut up and use Emacs" crowd.

Still, in order to be a happy user of Scala, you will need to put your trust in those people who forever go on writing near-incomprehensible blogs about monads and category theory. For example, as a user, I have no desire to actually understand "higher kinded types", but I happily take the result: By callingsomeCollection.someMethod, I get back another collection of the same type that I started with.

Like I said, plenty of Java programmers don't really understand Java, but they muddle through anyway. It is entirely possible that these programmers will be just fine with Scala. They would use a subset of the language, learn to stay away from the dark corners, and avoid the people writing those category theory blogs.

I think the people who complain most about Scala are the ones who would like to be able to grok the whole language, without wanting to learn more about programming languages than they already know. This approach worked great with Java 1.0, where the hard parts—GC and the JIT—are pretty well hidden. But maybe that was an outlier, and we just have to accept that the NBJL isn't going to be as simple.

In 2002, JSF was introduced at Java One as “Swing for the Web”. The vision was that you would compose professionally designed components into web pages, add a bit of Java glue code, and presto, you would have a web app without having to worry about HTTP or the DOM.

I perked up because I didn't want to worry about HTTP or the DOM. This was before Ajax was invented, and before I knew that I certainly didn't want to know about the XMLHttpRequest object or JSON.

Ever since, I have been fussing with JSF, not always happily. A couple of years, I wrote this blog about a JSF 1.2 project. I liked the Woodstock component set. But I groused about having to redeploy all the time, the stack trace from hell, and the lack of templating.

What a difference two years make. With GlassFish 3 and JSF 2, templating is easy, hot deployment works pretty well, and Facelets error reporting means that the stack trace from hell is much less common. (Now if the rest of Java EE could do as well and give me the source file/line number for each error...I am looking at you, Weld...)

However, as I ported an app to JSF 2, I had to give up on Woodstock. It has been abandoned and does not seem to work with JSF 2. First, my graduate student Ashlesha Patil provided a UI that used just the basic HTML components. It worked fine but looked rather plain.

So, I looked for another component set that was ready for JSF 2 and took advantage of its latest features. The one that seems furthest along is PrimeFaces (version 2.2M1). It is dead simple to use. No more wretched web.xml orfaces-config.xml customizations. Simply add the JAR toWEB-INF/lib and add

xmlns:p="http://primefaces.prime.com.tr/ui"

to each XHTML page. Then you can use goodies such asp:tabView and p:accordion. After an hour of fussing, the screen looks like this:

That's more like it. Clicking on the tabs and accordion buttons gives subtle animation effects, without any work on my part. There are plenty of themes to choose from if blue and gray aren't your thing. And of course, there are lots of components.

NetBeans 6.9 does code completion on the tags and presents the documentation:

NetBeans 6.10 will include PrimeFaces out of the box, so you won't even have to download the JAR.

After all these years, JSF is finally getting pretty close to its original promise. I really like that I can think in terms ofcomponents—such as the tab view or accordion component—without having to worry about HTML or JavaScript. And I can let someone else author these components.

The next step on my wish list is a JSF app framework—something that gives me the basic structure that is common to many apps. In particular, I never want to write the code for login and password recovery again.

Mark Reinhold just published a blog stating what has been painfully obvious to everyone following the JDK 7 development: There is no way that it will ship 2010. He thinks that mid-2012 would be realistic. Having followed the Project λ discussion, I can see where he is coming from.

He asks whether Oracle should just package up what is already finished, run it through QA, and slap a Java SE 7 label on it (presumably after having it rubber-stamped by a JSR). Java SE 8 could come at the end of 2012, coinciding with the end of the Mayan long count.

To nobody's surprise, almost everyone replied that it is better to have something now than maybe have something better later.

What will be in Java SE 7? Here is the list, to the best of my knowledge, sorted in the order in which they matter to me :-)

  • Performance enhancements and bug fixes
  • Automatic resource management
  • NIO.2 (the new new I/O)
  • The fork/join framework
  • Diamond operator
  • Annotations in more places
  • invokedynamic and an API for method handles. (I'd rate this higher if I knew
  • AWT/Swing tweaks: JLayer, translucent and shaped windows, and an “improved” security dialog
  • Minor language tweaks: strings in switch, underscores in literals, binary literals
  • Nimbus

What is missing?

  • Closures
  • The parts of the fork/join framework that depend on closures to be user-friendly
  • [] notation for lists and maps
  • Modularity (AKA “Project Jigsaw”)
  • Everything that already got dropped along the way for “lack of time”, such as the Swing Application Framework, bringing SwingX controls to the core API, date/time API

Now, this isn't the end of the world. Look at the Wikipedia Java version history: The most notable Java 1.3 enhancements, besides HotSpot, were JNDI, Java Sound, and CORBA support in RMI. Not exactly earth-shattering stuff, but at the time nobody complained about Java turning into COBOL.

I think what really made people unhappy is not the modest Java 7 feature set but the five year gap since Java 6. But that's water under the bridge. It's more useful to think about where we are going. Here I am only talking about Java SE, not EE or ME.

The Java language is now pretty much at the end of its evolutionary path. Sure, some form of closures will be nice, if and when they come. But the people who care about this kind of stuff have other choices, both on and off the JVM. I have no problem with that.

On the JVM, there is still quite a bit work that can and should be tackled—see this blog.

Where we are hurting are the Java libraries. They haven't seen much love for a long time. There is a good amount of cruft all over, not just in the date/time API. Client-side UI development is in particularly bad shape. I'd like a much richer set of Swing controls than what I had in 2002, an app framework that's at least as good as MFC was 20 years ago, and audio and video that actually works. And, no, I do not want another language to write my UI. If there is anything useful in JavaFX (such as the scene graph), port it back to Java SE! And, of course, fix deployment!!! On my Windows 7 laptop, I am still getting an error message (download of the latest Java version failed) whenever I click on that orange tray icon.

Another pet peeve of mine is the WebStart API. WebStart-in-a-sandbox is a great idea, but it can only work if the sandbox works well. Making users accept "all permission" negates one of the primary benefits of using Java in the first place. I want an API that “just works” when my app runs in the sandbox—today that's only the case for printing. And I want the kind of friendly end-user permission management that cell phone apps have these days.

There is still a window of opportunity for Java to regain traction in the cross-platform desktop space. Everyone loves to bash Swing, but if you need to bang out a cross-platform app that gets lots of data from the user (as opposed to having lots of eye candy), then Swing is pretty good. And there isn't a lot of credible competition: Qt, wxWidgets, pyGTK, or Mono/WinForms aren't exactly a walk in the park either. But that window will close. (BTW, I didn't think it was a good sign that the GlassFish update tool was written with wxWidgets.)

In summary, I am ok with a modest Java 7. I am ok with a Java language that won't evolve much more. But if the Java library doesn't evolve with the times, there is trouble ahead. In particular, on the desktop, the time has come to put up or shut up.

I am working on a web site that will help students practice their Scala programming skills. As I labored along, writing my JSF app code, I thought “this is silly—why not practice Scala at the same time?” But I like JSF and wasn't ready to jump to Lift or Vaadin.

With Eclipse, this isn't all that hard. Install the Java plugin. Make a dynamic web project in the usual way, using the Java EE perspective. Then, switch to the Scala perspective, right-click on the project, and, if all planets are aligned correctly, you will get a menu item “Add Scala nature”. (If they are not, see here for a manual approach.) Add your managed beans as Scala classes. Finally, switch back to the Java EE perspective, select the project properties, and add the Scala library JAR as a Java EE module dependency.

But I like NetBeans and wasn't ready to switch to Eclipse. (Unfortunately, JSF 2 support in Eclipse is pretty minimal, the Glassfish integration is a bit flaky, and the Scala plugin has very little usable code completion.)

NetBeans doesn't let me add a “Scala nature” to a web project. If I add Scala files to the project, I can edit them with the Scala editor, but they just get copied to the WAR file, without any compilation. I had one look at the Ant scripts for a Scala and a web project and decided that I wasn't going to figure out how to merge them.

This blog shows how you can use Maven to make a mixed Scala/Java project in NetBeans. So I gathered up JSF and Scala pom.xml files from here and here, cut out the considerable crud from the JSF POM file that was probably meant for supporting Tomcat, and merged the results to the best of my ability—see below.

You use the usual Maven directory structure, but with asrc/main/scala directory instead ofsrc/main/java:

This is the first example from Core JSF, but with a Scala managed bean:

@Named("user") @SessionScoped
class UserBean extends Serializable {
   @BeanProperty var name : String = ""
   @BeanProperty var password : String = ""
   def login = if (name != "") "welcome" else null
}

Now isn't that nicer than

@Named("user") @SessionScoped
public class UserBean implements Serializable {
    private String name = "";
    private String password = "";

    public String getName() { return name; }   
    public void setName(String newValue) { name = newValue; }

    public String getPassword() { return password; }
    public void setPassword(String newValue) { password = newValue; }   

    public String login() {
        if (!name.equals("")) { 
            return "welcome" 
        } else { 
            return null;
        }
    }
}

Here is a zipfile of the project. To test that it works, run

mvn package embedded-glassfish:run

Then point your browser to http://localhost:7070/scala-login, and the app should come up. Login with any non-blank user name, and you get this:

(Yes, it truly is JSF—the URL in the browser bar is one step behind...)

Now on to NetBeans. Select File -> New Project -> Maven -> Maven Project with Existing POM.

Just keep going in the wizard, and remember for next time that you could simply select File -> Open Project... instead.

What you get is pretty good—a project that you can build, deploy, and debug inside the IDE. Changes in the JSF pages are hot-deployed, but if you change your source code, you have to select the Debug -> Apply Code Changes menu option.

Also, you don't get autocompletion of CDI beans. Somehow NetBeans doesn't discover them from the deployed code. It does discover the message bundle for code completion, so maybe this is something they could fix in the future.

Here is the POM file:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" 
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">

   <modelVersion>4.0.0</modelVersion>
   <groupId>com.horstmann.corejsf</groupId>
   <artifactId>scala-login</artifactId>
   <packaging>war</packaging>
   <version>1.0.0-SNAPSHOT</version>
   
   <properties>
      <scala.version>2.8.0</scala.version>
   </properties>
   
   <repositories>
      <repository>
         <id>scala-tools.org</id>
         <name>Scala-Tools Maven2 Repository</name>
         <url>http://scala-tools.org/repo-releases</url>
      </repository>
      <repository>
         <id>maven2-repository.dev.java.net</id>
         <name>Java.net Repository for Maven</name>
         <url>http://download.java.net/maven/2</url>
      </repository>
   </repositories>

   <pluginRepositories>
      <pluginRepository>
         <id>scala-tools.org</id>
         <name>Scala-Tools Maven2 Repository</name>
         <url>http://scala-tools.org/repo-releases</url>
      </pluginRepository>
      <pluginRepository>
         <id>glassfish</id>
         <name>GlassFish Maven 2 Repository</name>
         <url>http://download.java.net/maven/glassfish</url>
      </pluginRepository>
   </pluginRepositories>
   
   <dependencies>
      <dependency>
         <groupId>org.scala-lang</groupId>
         <artifactId>scala-library</artifactId>
         <version>${scala.version}</version>
      </dependency>
      <dependency>
         <groupId>javax</groupId>
         <artifactId>javaee-api</artifactId>
         <version>6.0</version>
      </dependency>
   </dependencies>

   <build>
      <sourceDirectory>src/main/scala</sourceDirectory>
      <finalName>${artifactId}</finalName>
      <plugins>
         <plugin>
            <groupId>org.scala-tools</groupId>
            <artifactId>maven-scala-plugin</artifactId>
            <executions>
               <execution>
                  <goals>
                     <goal>compile</goal>
                  </goals>
               </execution>
            </executions>
            <configuration>
               <scalaVersion>${scala.version}</scalaVersion>
            </configuration>
         </plugin>
         
         <!-- Compiler plugin enforces Java 1.6 compatibility -->
         <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <configuration>
               <source>1.6</source>
               <target>1.6</target>
            </configuration>
         </plugin>

         <!-- Configure the Embedded GlassFish Maven plugin -->
         <plugin>
            <groupId>org.glassfish</groupId>
            <artifactId>maven-embedded-glassfish-plugin</artifactId>
            <version>3.0</version>
            <configuration>
               <app>${project.build.directory}/${build.finalName}.war</app>
               <port>7070</port>
               <containerType>web</containerType>
            </configuration>
         </plugin>
      </plugins>
   </build>

   <reporting>
      <plugins>
         <plugin>
            <groupId>org.scala-tools</groupId>
            <artifactId>maven-scala-plugin</artifactId>
            <configuration>
               <scalaVersion>${scala.version}</scalaVersion>
            </configuration>
         </plugin>
      </plugins>
   </reporting>

</project>

I am on sabbatical in Vietnam right now, and today the country celebrates independence day. (On September 2, 1945, Ho Chi Minh gave his declaration of independence speech.)

I read James Gosling's latest blog and wondered whether there ever will be independence for Java.

As James reminds us, there was a time when Oracle wanted to set Java free. I had naively thought we were pretty much there, with a JDK under GPL. But the situation is much murkier, and it is not at all clear under what conditions one can rely on a freely available Java platform as the foundation of one's work. I read Neal Gafter's blog, in which he writes: “Even though I am a contributor to openjdk7, I do not have a license to Oracle's patents that are necessarily infringed by the use of the openjdk7 source base.”

Presumably, there is a process by which Neal could get a patent grant, by getting a license for the TCK, and making his implementation pass it. However, a TCK doesn't yet exist for JDK 7, and the license is only good for GPL implementations that are “being substantially derived from OpenJDK Code”, whatever that may mean.

What's all the fuss about? First off, why GPL? That was so Microsoft couldn't “embrace and extend” Java. Fair enough. But why isn't there a straight patent grant that goes with any GPL implementation? As far as I can tell, Sun wanted to have their cake and eat it too: benefit from open source andkeep its mobile phone revenue. That's why we have the “field of use” restrictions.

For a while, it worked. Sun milked its Java ME platform for what remained of it in the feature phone business, ignored Google's “embrace and extend” of mobile Java for smartphones, and enjoyed the benefits of broad community involvment in the Java Community process. I know that many people complained about that process, and it had its problems, but it also delivered results. With one exception: the absence of a JSR for JDK 7.

I think it is no longer working. The Google lawsuit has brought the contradictions out in the open. Java is controlled by a single corporate entity, in much the same way that .NET is. Yes, you can make a GPL clone of JDK 6 that runs on desktops and servers. That's nice. But if you want to run Java on tablets, smartphones, or embedded devices, you'll pay. If you want to use a version of Java that is not “substantially derived from OpenJDK Code”, you'll have to negotiate a TCK license, which Oracle may or may not grant.

For a free software developer, what does that mean? We can almost certainly count on access to a free JDK 6 implementation. It's in our interest to get at least one such implementation, maintain it on free operating systems, and innovate on top of it, independent of Oracle and the JCP. However, there is no way of knowing whether language, platform, and VM innovations, if and when they do materialize, will be available freely, so we shouldn't count on it. As Neal points out, there is minimal incentive to be involved in their development. Overall, that is not so different from what one gets with .NET/Mono/C#.

Of course, Oracle may not care, and laugh all the way to the bank. Then again, how much mirth can there be? Java ME is a lost cause and revenue will dry up soon enough. The Google lawsuit may or may not bring in a bundle, but it may well take a while. There is no other substantial Java licensing revenue outside the mobile/embedded space, and the GPL JDK makes it hard to rustle up any.

So, maybe Oracle will see the light and set Java free? In the manner that they supported in 2007, with an independent foundation, with development funded by multiple parties? That will be a day to celebrate—independence day for Java.