JSR 299, WebBeans: Will EJB rise again?

Submitted by Rick Hightower on Fri, 2008/02/29 - 4:40am. (http://java.dzone.com/news/jsr-299-webbeans-will-ejb-rise)

"JSF really needs some major improvements" says Gavin King in a recent article on SD Times. Alex Handy wrote a short, interesting piece on JSR 299, Web Beans titled EJB's Path to Browser Takes Shape. The article covers Web Beans, JSF 2.0 and how Gavin King, the founder of Hibernate and Seam, wants to simplify web development for JEE so that it is as productive as Ruby on Rails and PHP.

There are some interesting quotes from Gavin King with regards to JEE needing to be trimmed down and where Seam and Web Beans fit in the JEE diet.

From previous posts on Seam and Orchestra, it seems that Seam is not really tied to EJB at all. And, you can easily use Seam without EJB.

So why do you suppose Web Beans/Seam is positioned as the way to get "EJB's Path to Browser"?

Will EJB see a reemergence through Web Beans and Seam?

What do you think of Gavin King's position on JEE, EJB, JSF, Seam, and Web Beans as stated in the article by Alex Handy?

Will groovy will replace the Java language as dominant language?

Submitted by Steven Devijver on Wed, 2008/02/13 - 4:32am. (http://java.dzone.com/news/groovy-will-replace-java-langu)

Hear me out. In 2 to 3 years from now there we will see strong indications that Groovy is replacing the Java language as the dominant language on the JVM. Actually outnumbering the Java language will be very hard, given its 10+ years of history. But the trend will be clearly with Groovy.

I realize this sounds like an extra-ordinary claim, maybe even sounds baseless. But it's not. I've recently come to terms with the increased adaptation of Groovy as a programming language myself. Before laying out my arguments to support the increasingly important role of Groovy, let me first lay out some of the history of the Groovy language.

The Groovy project for a long time has been a wild dream. Groovy is the dream child of James Strachan, extravagant open-source developer and visionary. While waiting for a delayed flight he was playing with Python and found it such a cool language that he decided the JVM needed to have a language like this too.

Groovy has always been closely related to the Java language. Not only is the Groovy syntax similar to and often identical to the Java syntax, Groovy is the only language together with Scala and of course Java that always compiles to true Java byte-code. This means that Groovy classes are always true Java classes.

But Groovy has known a rough history. I'm sure many people would prefer not to be remembered, but Groovy was on the brink of failure in 2003/2004. It got a lot of bad press back then and was written off by many people, including people that were involved in the project. Groovy made it through this storm thanks to the hard work of a team of very dedicated people. At the start of 2007 Groovy 1.0 was released and now we're looking forward for Groovy 1.6 and Groovy 2.0.

From the period of Groovy's near failure I remember that everybody had an opinion of what Groovy had to be like. Most people liked the Groovy language, but it had to be more like Perl, or more like Ruby, more functional, less Java, more Java. Every week there were enormous discussion on the mailing lists about which features Groovy had to support. This chapter in Groovy's history is behind us.

Since 2005 the Groovy team has regrouped and been working hard to improve the language. They've incorporated many suggestions and continue to do so until this day. But you won't find many discussions today on which direction Groovy should take. We're past 1.0, the language is stable.

Groovy is a dynamic language, meaning Groovy does not do type checking on variables if you don't want it. Groovy can do type checking but its optional. Here's an example of Groovy code that does not do type checking:

1. def list = []
2. assert list.empty

def list = []
assert list.empty

Here's the same code with type checking:

1. List list = []
2. assert list.empty

List list = []
assert list.empty

In a way, the Java language is a non-dynamic language that always does type checking.

So, why do I think Groovy will replace the Java language as dominant language? I'll break down my arguments in two categories.

First, why the Java language won't remain the dominant language:

• The Java language community is sinking into a deep crisis over change. There's the row over whether or not closures have to be added to the Java language, and which proposal should be selected. This reminds me of Groovy's history. With each change to the Java language tool vendors have to adapt with it. This is a slow process, and the closure proposals I've seen are not nearly as powerful as closures in other languages, including Groovy. Adding this kind of features can happen a couple of times. The pressure to consolidate will however increase. By the time this happens we're 2011. The Java language will have new features at the expense of several massive investments by many parties who will grow increasingly impatient.
• Java language changes are driven by Sun and marketing. C# gets annotations, Java need to have annotations. C# gets closures, Java needs to have closures. See the pattern? This does not serve the Java user community. Actually, we're completely shut out.
• The Java language will be forked. As some people will grow more frustrated with the way the Java language is managed there's a very real possibility that the Java language will be forked, even if it's only for the sake of creating prototypes or making a point. This may be conceived as dangerous or at least make some people nervous, re-enforcing the point for the design-by-committee culture even more.
• Static typing is a great feature and every object-oriented language needs it. It's not so great when there is no alternative. For example, it's unlikely that new methods will be added to the java.util.Collection interface to support closures. For Groovy dealing with new methods on java.util.Collection would be a non-issue. This feeling of being stuck with certain types will increase the sentiment that the Java language may be at a dead end.

So, then why should Groovy become everybody's favorite, especially now that Sun officially supports JRuby? And what about Scala?

• Sun supports Groovy too. Some of their employees are working hard on the Groovy plugin for the NetBeans IDE.
• Of Groovy, JRuby, Scala it is Groovy that comes closest to the original Java syntax.
• Java should always have been a dynamic language. Groovy gives us a glimpse of what the Java language could have been.
• IDE support for Groovy will be very impressive in one year from now or less, making its integration into projects much more likely.
• Dynamic languages can have very good IDE support like type detection and code completion. If Visual Studio can have excellent integration for F# then the same is possible for JRuby and Groovy as well. In fact, the NetBeans IDE plugin for JRuby is already impressive.
• Groovy offers joint Java compilation, meaning that .java and .groovy files get compiled at the same time. Java classes can thus extend Groovy classes without a glitch.
• As Groovy IDE support improves - which is already decent for IntelliJ - more and more frameworks for Java will be written - at least in part - in Groovy. This is already happening. Don't expect the same to happen for JRuby. It could happen for Scala.
• Two to three years from now the performance of dynamic languages like JRuby and Groovy will be equivalent to pure Java code.
• Grails 1.0 is a huge step for the Grails and Groovy communities, but it's a small step compared to what's ahead of us. Both in terms of Grails and in terms of new ideas.
• As Groovy starts to play an increasing role in software development an increasing number of developers will be touched. Think Grails, think easyb, think of some novel new use of Groovy yourself.
• There's genuine interest in Groovy and Grails, and it's growing. Now is our moment to seize these opportunities and make it easier for people to start using Groovy. The trend is with us, let's make it stronger.

It's going to be a very interesting 2 years for Groovy and Grails. The moment is ours and the demise of the Java language has to be Groovy's stepping stone.

Happy coding!

Naked Objects 3.0 for Java

Naked Objects ?
Naked Objects is an open source Java-based application development platform.
It’s called Objects because all you need to develop are your domain objects - the Naked Objects platformNaked auto-creates an object-oriented user interface (giving you the choice of
different styles) and the underlying database (using Hibernate).

Can I use Naked Objects to prototype an application that will be deployed on a different architecture?. Absolutely - in fact most people start to use Naked Objects initial for prototyping only and only later consider using it as a full deployment platform. The domain objects that you create for Naked Objects are Plain Old Java Objects (POJOs) - they aren't tied to Naked Objects in any way. So if you want to develop a hand-crafted user interface to invoke the objects' functionality, you can.

To what type of applications is Naked Objects best (and worst!) suited?. The auto-created user interfaces give the user a great deal of flexibility and control, but the corollary is that it does take a short while to get to know that user interface. So Naked Objects is best suited to the kind of in-house application that people use intensively; it is not at all suited to applications intended to be used by people with no training (for example a public web-site). However, per the previous question, there is nothing to stop you from developing a Naked Objects application for internal users, then building a more conventional tightly-scripted interface to the same domain objects, for use by external parties.

Do I have to use Hibernate?. No, it is possible to write alternative object stores to work with Naked Objects. For example, the download includes a simple 'XML Object Store' that is useful for prototyping purposes.

Top Five Java Technologies to Learn in 2008

Carlos Perez has posted his list of the top five Java-based technologies to learn in 2008. (http://www.manageability.org/blog/stuff/five-java-technologies-to-learn-in-2008).

Software Technology will always been in constant flux. Change will always be inevitable. So as a Java developer you need to continue to groom your career by learning new techniques and technologies. It's both a curse and a blessing. It's a blessing because Java, without a doubt, is where a lot of innovation happens. The question though is, out of the multitude of Java projects out there, which ones should we invest our limited bandwidth on? This is my attempt at answering this question.

Here is what I humbly believe to be the top 5 Java based technologies to learn in 2008:

• #5 OSGI - Reality check, monolithic containers carry too much baggage and Java libraries are so richly cross dependent. The trend is there, a lot of frameworks are moving towards OSGI to bring some sanity in their deployment. Projects that have employed OSGI in anger are Eclipse via Equinox, Nuxeo and BEA Event Server,
• #4 JCR - Reality check, not all data fits well within a relational database. In most cases, users want to store their own documents and have those properly managed (i.e. versioned). JCR with it's Jackrabbit implementation is becoming the de-facto standard for maintaining data other than the structured kind. Some examples of projects that have used this in unexpected and innovative ways are Drools BRMS for managing business rules, Apache Sling for universal resource storage and Mule Galaxy for SOA governance management.
• #3 GWT - Reality check, AJAX is here to stay and Javascript is still a pain to work with. GWT is gaining traction like wildfire at the expense of other Java web technologies like JSF. A lot of projects have begun creating extremely cool products with it. Some impressive examples are Queplix a CRM, Compiere an ERP and GPokr a multiplayer Texas hold-em poker game.
• #2 Groovy - Reality check, sometimes you have to write quick and dirty scripts to get your tasks done quickly. There's a lot of traction these days for dynamic scripting languages like Ruby. However if you want to truly leverage your existing skill set, then it's more efficient to take a evolutionary step. Groovy has come a long way since it's rocky beginnings. I believe Groovy is finally mature enough (it finally has a debugger) that it's safe to dip your toes in it. Furthermore, there's are a of books, books about frameworks (i.e. Grails) and tools (i.e. IntelliJ) that help you from getting lost.
• #1 Cloud Computing - Reality check, sometimes it just isn't worth it to setup your own physical servers. Amazon's services are going to be an extreme boon to development productivity. One of the most time consuming efforts, and one that is too often taken for granted, is the deployment of a load and performance testing harness. In a lot of rigid organization, it is sometime problematic to acquire so much hardware for use only for short time periods. There aren't many tools out there yet for the Java developer (see: "Grid Gain Distributed JUnit"), however it's ramping up pretty quickly. So just as we create our builds from the cloud via Maven repositories, one shouldn't be surprised to find cloud based testing resources to be part of every developer's tool chain in the future.

With all these nice new shiny objects to play with, I'm constantly surprised why people keep claiming that Java is dying!

I'm certain you are all agreement with me on what belongs to this list. However if you've got some violent objections, I certainly would like to hear your view.

Here are the "Top Five Java Technologies that Did Not Make the List"

• #5 Android - Google's attempt to turn the telco space on its head. This is expected to be not only game changing but disruptive. I of course will like to wait for (a) an actual hardware device to play with (b) Google winning the 700Mhz spectrum and (c) the deployment of 700Mhz cell towers across the states. The problem I have with Android is the problem the plagues J2ME devices. How do I keep my sanity as the variety of mobile devices increases exponentially? I have yet to have heard a compelling story (OSGi perhaps?) in this area. That's plain unfortunate because it's the biggest pain point for mobile developers.
• #4 JRuby - Rails is certainly getting a lot of attention; JRuby channels that attention towards the JVM. The Ruby job market has grown to a stunning 3.3% of the size of the Java market. If you need something new (don't ever try this with legacy code) then possibly the quickest route to a working application is via Rails (use Streamlined while your at it). However, not all applications consist only of CRUD screens, you'll need to add more mojo into it. That's when you have to question Rails viability. Convention over configuration only works well if you're building something conventional.
• #3 Scala - Scala is a brilliant well thought out language. It's a language that is not only extremely expressive but one that doesn't have the performance baggage of a dynamically typed language. In short, you could use it to build bleeding edge infrastructure stuff. The kind of stuff you would never dream of building using slow as molasses languages like Ruby. Sure, you have to subscribe to the static typing religion, it's an unfortunate trade-off you have to make if you want to build really tight systems. It however didn't make the list because I would only recommend it to 'rocket scientists' building serious heavy lifting infrastructure. Web front end developers need not apply.
• #2 Seam - Gavin King (Hibernate's creator) is an accomplished developer. So when he builds another framework, it behooves you to take notice. Seam is his latest creation and it merges JSF and EJB3 into a seamless workable framework that's all hangs together with Annotations. Unfortunately, its strength is also its weak spot. All that annotation work is going to be a nightmare to debug. Personally, I think Spring is good enough, however if you must have an overarching framework then Seam would be it.
• #1 Flex - If anything should have been on the list, this would be it. If you want to build rich applications on a browser then plain DHTML and Javascript isn't going to cut it. The most innovative desktop like applications on the web are unfortunately built on Flash. GWT isn't going to help you build applications like YouTube, Mindomo, Buzzword, Sketchcast or Pandora but Flex will. The bad news is that Flex isn't Java, however the good news is that Adobe's soon to be open sourced server (BlazeDS) is thankfully in Java.

Grails 1.0 released!

Submitted by Steven Devijver on Tue, 2008/02/05 - 6:17am. (http://java.dzone.com/news/grails-10-released)

Graeme Rocher just announced on the Grails mailing list the release of Grails 1.0. I'm very happy to announce this news here on Groovy Zone since more than 2 years ago I stood at the cradle of Grails together with Graeme, Guillaume La Forge and Dierk Koenig. Grails, Groovy and the entire Java community has gone a long way since then.

Grails has seen the rise of many competitors since its inception. JRuby on Rails has become a reality. Seam is going strong. Yet the popularity of Groovy and Grails is undeniable, as the traffic on Groovy Zone indicates.

Thanks to the Grails development team for all the hard work. Grails went through quite a few refactorings. Out of this came ExpandoMetaClass which helped to re-write the Meta-Object Protocol in Groovy 1.5. I also like BeanBuilder, a Groovy builder for configuring a Spring ApplicationContext.

For me Grails is the ultimate rapid prototyping platform for Java. I've built numerous applications by dropping in existing Hibernate-configurated classes and generate scaffolding views. It gets you started really quickly and helps you to focus on the application you're building.

GSP and the Grails tag libraries are amazing, they're so much better than JSP tags. And lets not forget the numerous Grails plugins. The Search plugin is terrific, it instantly adds search functionality to your application. Check out all the Grails plugins for your needs.

Download Grails 1.0 here. Read the user guide here. Watch the screen casts here. Check out the Grails and Groovy books here.

Happy coding!

Why Microsoft Needs Yahoo: the Real Story

Submitted by Ivo Jansch on Sun, 2008/02/03 - 1:52pm. (http://java.dzone.com/news/microsoft-and-yahoo-real-story)

So one day, Scott McNealy, founder and chairman of Sun, read in his morning newspaper how the use of Java was rapidly diminishing, courtesy of something called 'The LAMP Stack'. Furiously, he called his accountant.

Scott: "I knew this Java thing was a bad idea in the first place! I see only one solution. We need to buy this Lamp!"
Accountant: "Euh, LAMP is not a company. It's an acronym. It's Linux , Apache, MySQL and PHP"
Scott: "Then buy me Linux!"
Accountant: "But we still have this Solaris thing.."
Scott: "Then buy me Apache!"
Accountant: "That's a foundation. Nothing to buy there."
Scott: "Then buy me MySQL!"
Accountant: "We don't do databases."
Scott: "It's a database?"
Accountant: "What rock have you been living under?"
Scott: "Sweet. I can own the Lamp AND piss off Oracle at the same time!" (waves fake plastic magic wand) "Make it so!"

And so it happened.

Ten days later, Microsoft CEO Steve Ballmer was reading the CIO Magazine, and read about this interesting thing called PHP, that according to the author you could use to write "WHAT?!". "WHAT?!", obviously a highly advanced and evolved version of "Hello World", caught his attention. So he called Bill Gates.

Steve: "Hey, you heard about this PHP thing?"
Bill: "Pee Age Pee? You're not that old yet, are you?"
Steve: "What? No, wait, it's a programming language, apparently better than ASP.NET."
Bill: "Who cares if it's better. I mean; we made the worst operating systems ever and still rule. (Checked out Leopard yet? It is SO cool.)"
Steve: "I don't know Bill... remember that internet thing that we didn't know about years ago? Kind of nearly missed the boat there."
Bill: "Right. Didn't we solve that in the same way? Worst browser, highest market share, that sort of thing?"
Steve: "Yes we did, but then we also didn't know about this 'mp3' thing until it was too late."
Bill: "We did manage to make Zune the worst player, but somehow we're not market leader. Guess we got sloppy?"
Steve: "Maybe it's just different times. Maybe we should have a different strategy."
Bill: "Ok, so let's just buy PHP then."
Steve: "It's not a company. But Encarta says it's written by a Rasmus Lerdorf."
Bill: "So let's hire him."
Steve: "Tried that. Didn't want to join. Can't blame him, works at Yahoo."
Bill: "Then I guess we'll have to buy Yahoo."

So it happened.

Two of the most controversial announcements of this month, and both appear to be part of devious plots to take over the LAMP stack. What's next? My prediction: Red-Hat buys Zend; Oracle buys Red-Hat; Sun and IBM join forces to buy Oracle, Microsoft buys Sun, kills IBM and peace is restored in the galaxy.

P.S. Can you imagine Microsoft running sites like Flickr? These guys invented MS Paint!

Eclipse - GWT Tutorial

This tutorial by Prakash G.R. introduce you to GWT using Eclipse.

You can do develop GWT apps without any IDE, but it is really helpful if you use one. I choose Eclipse with Cypal Studio for GWT (which was earlier known as Googlipse) to walk thru this tutorial.

Follow the link for the tutorial: GWT Tutorial