Tuesday November 22, 2005

Graham Hamilton recently posted an entry on his blog requesting suggestions for future Java language innovations. I work with Graham, and have had the opportunity to talk with him about a wide range of Java subjects. One place where we haven't seen exactly eye-to-eye is the area of language-level properties and events. I personally believe this is the #1 missing ease-of-development feature in the Java language (and platform, for that matter).

Adding properties and events to the Java language itself does more than eliminate common boiler-plate code, as is often used as the primary pro argument. The more important benefit of adding these concepts to the language itself is that it promotes the notion of "component library" instead of "class library" when designing new APIs and systems. Component-based development is what makes learning and developing with some "other" software platforms so much easier. The Java language is still very focused on the notion of "class library", which was long ago supplanted by "component libraries" in other platforms.

JavaBeans has been around for a long time. It was the *original* move toward component-based software for the Java platform. The notion of components promotes a plug-and-play method of software development where the common interfaces between components and an application are well defined. This makes it very easy for visual tools to aide in application design and building. It also makes it very easy for new concepts to be introduced to the end developer. A developer is handed a set of JavaBeans which they can study and poke-around with until they learn the new concepts implemented by the suite of JavaBeans. The only problem is... JavaBeans is just a conventional pattern, and not built into the language itself, and therefore completely ignored in most APIs. New technologies and APIs rarely use JavaBeans patterns, and the JavaBeans patterns themselves have gaping holes where tool vendors have had to fill in the gaps.

If these component-oriented concepts were in the language itself, they would be used across the board for new technologies. Any new API (or JSR, etc) would provide a set of components for a developer to use, as opposed to defining a set APIs to implement or leverage. Things would just be easier - both for tool vendors - and for end developers.

I have compiled my thoughts into a document that outlines how this might be accomplished. Please comment!

Tuesday November 08, 2005

    ArrayList<Donkey> donkeys = new ArrayList<Donkey>();
    ...
    for (Donkey d: donkeys) {
        d.doDonkeyStuff();
    }

The new simplified for loop construct is wonderful... but even better is the fact that you can create your *own* classes that leverage this new iterator type. All you have to do is declare a class (or interface) that implements (or extends if its an interface):

    java.lang.Iterable<T> or basically just Iterable<T>

If your class implements Iterable<Donkey>, then folks using your class can use the nifty new for syntax to automatically iterate each Donkey. Its beautiful and very elegant!

An example usage:

    public class Donkey {
        ...
    }

    public class DonkeyCorral implements Iterable<Donkey> {
        ...
        private ArrayList<Donkey> _storage = new ArrayList<Donkey>();
        ...
        // This example returns my generic storage collection's iterator,
        // though I could do whatever here...
        public Iterator<Donkey> iterator() {
            return _storage.iterator();
        }
        ...
    }

    DonkeyCorral corral = new DonkeyCorral();
    ...
    for (Donkey d: corral) {
        d.doDonkeyStuff();
    }

Thanks Tor - for setting me straight and fixing my code sample! That's what I get for going from memory and not looking at my own code while typing a blog entry!!! Hey! We need a blog entry module for NetBeans! I'd like to be able to blog from inside the tool! Get on that Tor!

Monday October 31, 2005

I was just scanning some docs on a web framework today, and I came across a term I have seen a lot of recently. "Inversion of Control" is essentially proper use of JavaBeans events for server-side folks that didn't get it the first time around when JavaBeans was introduced. One of the biggest points to having a real component model (JavaBeans) built into a platform (and ideally a language), is the ability to encapsulate complexity. Ideally, an end-developer doesn't need to understand all the details of a complex system. A handful of well-designed JavaBean components can encapsulate enough functionality to make programming a web, desktop, or mobile application a quick task. Unfortunately, the Java web-tier folks did not "get" this point until relatively recently. Web frameworks have traditionally been very code and XML configuration driven, and have not leveraged the power of component encapsulation. This latest trend is wonderful, but very late to arrive on the Java scene. JavaServer Faces (JSF) components are the closest I've seen yet to proper components on the web-tier.

Wednesday September 28, 2005

Java is a great language for creating applications, and a great runtime platform for deploying applications. The evolution of Java can be traced fairly easily by a large number of folks that have been involved since early on (including myself). What puzzles me today is the fact that we *still* have such divergent mechanisms, libraries, and techniques for writing applications to be deployed on the desktop, server, and mobile devices. Why do we have 3 versions of the Java platform? I certainly understand the history, but the future points at convergence of these! The lines between desktop, mobile, and web applications are blurring at an alarming rate folks!

If you take a look at the APIs in these three spaces, it almost seems like the there is a lack of communication between the respective groups. JEE guys don't talk to JSE guys and JME guys don't talk to JEE or JME guys... etc... Is this true? Are the three Javas developed independently from eachother?

What I would like to know is if you, the Java developer (not the developers of Java), work in more than one of these areas. I would like to know how many Java developers "cross boundries" and work in more than one of the three "versions" of Java. If there are any of you out there... how difficult is it to context-switch your thinking between the different ways of doing things with Java? Is it hard to build a Swing app and then switch to building a mobile app? How about a web app with JavaServer Faces - then build a desktop GUI with Swing? Or SWT? Do you get to share any code between these applications? Is that too difficult? What would you like to see in the future?

If you can't glean my opinion from the tone or questions I raise... I would like to see the three Javas converge. In my opinion, we need to make ONE Java, where an application developer can freely dance in the web, desktop, or mobile space without having to re-tool or relearn a new set of APIs. We need a unified notion of components. We need a unified notion of data-binding. We need to push Java toward the future of applications, which will freely span all areas they have touched before.

And, lest I forget... I hope you realize that there are several more "areas" of applications then the three mentioned above. For example, voice applications will also emerge as a strong mainstream contender now that VOIP is coming of age... They've been around for a long time, but now they will rapidly become popular. Just watch.

Wednesday September 07, 2005

I hosted a TopCoder chat today, where folks asked various questions about Sun, Java, and Creator. You can see the transcript here. We got into some pretty interesting stuff - including a some talk about SWT! Oooohhh...

I'll be speaking next week at the SDForum event at PARC in Palo Alto, CA. The day-long event is titled "Web Based Architectures: Where do we go from here?". The event is on Wednesday, September 14 2005, 8:30AM - 3:30PM at PARC, 3333 Coyote Hill Road, Palo Alto. I'll be a panelist in the last session at 2:30pm called "Web Architecture: Tools and Techniques". The panel will discuss the tools of the trade and how folks have been building (and will be building) web applications of the future. Come check it out!

Tuesday September 06, 2005

Hello folks! The JSR-273: Design-Time API for JavaBeans, or "JavaBeans2" as folks have been calling it is underway! Please have a look at the public project on Java.Net: "jbdt-spec-public". There you can find the latest code and JavaDoc for the JSR-273 API. Please make comments!!!

Thursday June 23, 2005

I've been a busy bee preparing for JavaOne. It is next week (June 26-30) in Moscone Center in San Francisco. I am only presenting in one session, BOF-9296, where I'll be explaining the main concepts behind JSR-273: Design-Time API for JavaBeans.

Stuff I've been working on will be shown several times during the conference, including the opening keynote, where Tor will be showing some *very* cool future technology stuff (can't talk about it here). He'll be using Creator to do his demo. There's a good session highlighting the new features of Creator: What's New in Sun Java Studio Creator. We also put together a JSF component vendor panel, most of which will be showing their wares in Creator.

There are hundreds of great sessions, and several great parties! See you there!

calendar

search

navigation

links

rss feeds

referers

Today's Page Hits: 52