Happy New Year! I trust you had a good festive break...not drinking or eating too much. Who am I? Good question. My name is Keith Brown and I'm the new J2SE editor of Java Developer's Journal. As this is the first issue of the new year, our editor-in-chief felt it was the perfect time for me to kick off and bring my flavor of Java to you each month.

My professional history is varied, so the least said about that the better (only joking). I'm a seasoned developer with nearly ten years of software engineering behind me, five of them spent working with this beautiful language we call Java. I've been involved with Java at many levels, mainly at the client-side, as opposed to the trendier jet set who specialize at the server-side. When Alan first spoke to me regarding this role, I was excited about his vision for the magazine. Since it aligned with my own beliefs regarding software engineering, I felt I could take this role and do it justice.

As the newest member of the team, I would like to spend a little time discussing my own personal views on the state of the industry, and where we can work together to make sure we are suitably armed with the tools to implement solutions for the next wave of problems that are winging their way toward us.

Did you catch last month's Guest Editorial from Eric Shapiro? Eric managed to encapsulate the very mood of the J2SE movement. As he said, people are quick to automatically dismiss Java to the server-side, automatically reaching for infamous phrases such as EJB, JSP, and JMS. But Java is more than just server-side - look at our J2ME section if you have any doubts.

I'm here to help reinforce the case for Java outside of the server world. Swing has had a bad rep to deal with; in fact, the history of GUIs in Java isn't a pretty one. When Java first burst onto the scene we were stuck with AWT. When Windows and even X-Windows had all these fantastic APIs, Java developers were definitely at the bottom of the heap with AWT. But it has to be said that the efforts of developers to produce beautiful client-side applications were admirable considering the tools they had to work with.

There was hope. We were told of a GUI API that would allow us to get to the tools we needed to produce production-quality, client-side applications, a GUI that would offer the flexibility and speed of any native platform-specific tool, a GUI to finally bring Java to the masses. Wow - sounded too good to be true.

Sadly it was. What finally arrived was something that was definitely a far cry from the pipe dream we were all living in. To say Swing was a disappointment to some would be a bit of an understatement. The system was buggy, slow, and very inflexible to porting. Maybe it was rushed out the door too quickly and people expected too much from it initially. After all, the APIs it was competing against had been seasoned over many years with a huge amount of testing and development invested in them. Swing was finding its feet with a very demanding audience.

I think that's one of the reasons why Java's popularity grew so quickly at the server-side. Technologies such as servlets and then JSPs made it very easy to build front ends to applications that could be quickly and easily deployed to the masses without worrying about extra downloads - in other words, the very premise that Swing was hoping to solve, but never quite got there due to its size. Even today, if you surf to a page that has a Swing applet, the browser goes into a bit of a fit; if you're really unlucky, you'll have just incurred a 10MB download, worse case.

Swing has never managed to quite get there, but after a number of years in development, the time has come to start delivering on some of its promises.