Nov 28

Java web frameworks ready themselves

Java, Tech, Web Frameworks 3 Comments »

The troops are showing signs of grouping together. Java has been under attack from other platforms. We have the ASP.NET side, and now the main source of discussion, the dynamic language side (principally Rails, but also Django/TurboGear/etc etc).

The Java side knows that in-fighting isn’t good anymore, so we are seeing more and more of the groups working together.

At first the troops gathered around the Java Web Alignment Group, a loose affiliation where nothing has really happened (it is very new).

I think it was a “we should work together!” cry, with no hard action items.

The Spring guys saw JBoss Seam, and talk of Clarity came together (along with other folks).

I certainly feel that there is room for common Java stacks, and Spring is a project that can pull this off.

Now, even more recently, a new force has entered the fray. It is the joining of WebWork and Struts. The WebWork guys have already been working with the Struts TI guys (using XWork), and I think it is a great fit.

Struts has the name. WebWork has the technology.

I can’t wait to see what comes out of the Struts Action Framework 2.0.

It is important times for Java frameworks, to see if they can compete with the simplicity and productivity of some of the other frameworks (including some of their own like RIFE).

Let the games begin.

Oct 03

Apache Beehive 1.0

Java, Open Source, Tech, Web Frameworks 4 Comments »

It was great to see an email from Eddie O’Neil from BEA, announcing the Apache Beehive final 1.0 release.

I got to work on an Apache Beehive project, and was very impressed with certain parts and pieces. This may be a 1.0 release, but remember that it has been around for awhile in production projects such as Portal, and Workshop.

Nice work lads!

We are pleased to announce the v1.0 release of Apache Beehive!

This release provides the following major features:

  • NetUI (Page Flow + JSP tag library)
  • Controls framework
  • System controls for accessing JDBC, JMS, and EJB resources
  • Many bug fixes
  • Significantly enhanced documentation
  • Additional samples

Binary and source distributions can be downloaded via an Apache mirror from:

http://beehive.apache.org/releases/release-1.0.cgi

Documentation for v1.0 is here:

http://beehive.apache.org/docs/1.0

A few notes about this release:

* WSM and the web service control are not included as WSM has not passed the JSR 181 TCK yet. Both will be available in a subsequent release.
* v1.0 does not include XMLBeans due to licensing issues with the JSR
173 API JAR; however, XMLBeans can still be used with Beehive and is available from http://xmlbeans.apache.org
* Changes in v1.0 from v1.0m1 can be found here:
http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=10570&fixfor=12310123
* Thanks to everyone who submitted bug reports, patches, testing, and feedback. All of these contributed significantly to this release.
* Please send comments / questions about this release to user@beehive.apache.org and development-related issues to dev@beehive.apache.org
* Bugs found in 1.0 should be filed in JIRA at http://issues.apache.org/jira/browse/BEEHIVE
* This version was built at SVN change 291405.

We welcome your feedback.

On to v.next…

The Beehive Team

Sep 25

War of the Web: Revenge of the Dynamics

Ajax, HTML, Java, JavaScript, Lightweight Containers, Microsoft, PHP, Perl, Ruby, Tech, UI / UX, Web Frameworks 933 Comments »

As I was watching “24 hour party people” on DVD, I heard the main character talk about the ebbs and flows of the music business. He is talking about the scene in Manchester at the end of the 70’s, and into the eighties. Moving from Joy Division to Happy Mondays and New Order.

I think that we are in a new chapter for the web, and as is often the case, the wheel of time is repeating history for us.

There are a few dimensions to the current war though. They are on the client side (DHTML Ajax vs. simple HTML vs. Flash/PDF vs. XAML) and on the server side (Rails vs. Java vs. PHP vs. .NET).

Let’s start at the beginning.

Perl: Birth of CGI

Do you remember how the web changed as it moved from static HTML connected content to dynamic websites? That came about due to CGI, and how our nice web server would now fork off our programs to generate the HTML.

I remember my first CGI programs were written in C, and Scheme. I quickly moved on though, and found the beauty, and craziness of Perl.

I spent quite some time with Perl, trying to get by without writing too much NSAPI and ISAPI code (oops, I guess that core dump hurts the entire server?).

I really enjoyed the community at that time. #perl was interesting (some of the time), and CPAN became the holy grail. As soon as you thought you needed something, someone had kindly put that functionality up into CPAN. I even have some of my own modules hanging out there, and helped with others.

Over a short time period, we had developed some fairly rich web modules. We didn’t have to work with $ENV{’SOME_CGI_ENVIRONMENT’}, or STDIN or the like. Our framework abstracted all of that for us, and gave us a simple model. We lauched at the folks who generated html via methods such as b("whee") and we stuck close to HTML itself, allowing our design teams to simply open the html files and see what their stuff looked like. We even had the notion of components, and special tags that you could create. <$mytag name=”…” /> was nice because the name of the tag was the key for the framework to dynamically discover that functionality. No config files, or interfaces, in the strict sense. The coupling was based on a name.

In retrospect, life was pretty simple for web development, a lot simpler than some of the frameworks we have today!

But, we moved from Perl. CGI was not the nicest for our high load servers. It was crazy to think that we would fork a process for every little request that came in, and that a Perl interpreter would start up, load the program, do the work and then die off.

We naturally moved to solutions such as mod_perl, and that helped. It was so new though that it was buggy and we had a lot of problems. Some of the problems had nothing to do with mod_perl itself, but due to laziness and side-effects.

When you work in an environment like CGI you can be a very bad man indeed. If you don’t close something correctly, or don’t play totally nice with resources, baaaah who cares? The server is going to kill me in 2 seconds anyway, so I will get my job done and have him kill me. In mod_perl world though, these programs start to live longer, and they get fat and oily.

Java: No more stinking processes!

Remember the beginning of Java (Oak!). We were building applets, and feeling the pain very early on.

Servlets were the big thing though. We ported our Perl based framework over, and were able to see significant performance improvements at the time. Some of the team loved the change, others hated the verboseness and static typing.

The nice threading model that Java gave us was huge though, even with the poor JVMs back then (Microsofts was by far the best remember!).

This is when we moved from the world of Perl to having Java start to take over. That isn’t to say that there wasn’t competition. In the waters we saw the lurkers of ColdFusion, ASP, and the beginning of the PHP revolution. Java came up with JSP to compete with these tag based approaches, but it was the advent of the rich MVC style frameworks that really spurred everyone on.

In my opinion Java is still in the hot-seat, especially in the corporate world.

Preparing for the server war

The troops are being gathered. Strategies are being worked out. We are currently getting ready for a new battle on the server side.

What’s happening?

  • Ruby on Rails: Whatever you think about Rails, it has lit a fire under the server side web development community. Many have jumped on the bandwagon, claiming real productivity improvements. Some of the PHP converts enjoy a richer language, which is still nice and dynamic, with a framework that enforces clean MVC techniques. Some of the Java community are frankly a little bored of Java, and enjoy the new challenge. They also love the freedom of the language, and the fact that they now have just ONE stack to worry about. Will the Rails buzz keep growing? Will it be the Perl of Web 2.0?
  • Java: Java isn’t going down without a fight. Some argue that the problem with web development in Java is that it has been too complicated and heavy for much usage. I have personally called for the need of a common stack for Java, and people have stepped up to the plate. On one side we have companies that will certify a set of technologies (JavaServer Faces + Spring + Hibernate). Then we get frameworks taking on simplicity themselves (WebWork now embedding Spring). Finally we have initiatives like JBoss Seam, which is trying to combine the component models of JavaServer Faces and the backend. Seam aims to give you the power of the Java tier, but also giving you a simple productive environment. So, Java frameworks are rising to the challenge of Rails, and we will soon see how much of the success of Rails is Ruby, and how much can be duplicated in other platforms.
  • PHP: We can’t discount PHP. A lot of “serious engineers” (read: anyone who isn’t a PHP developer thinks they are serious) poo poo the PHP world. Yet, by all accounts, there is a LOT of PHP development going on out there. PHP has the advantage of being something written JUST for the web. Take a look at how Wordpress came along (PHP based blogging software) and in no time at all there were thousands and thousands of plugins that you could simply drop into your Wordpress system. Literally, you drop in a file and you are done. There are numerous PHP frameworks that are aiming to mimic, and compete with Rails, so we can’t forget about these guys. The question with the PHP community is: will it grow more into the enterprise, or will it be for script-kiddies.
  • .NET: Never discount Microsoft. ASP.NET keeps getting more productive, and it is hard to compete with their end to end story, which includes fantastic tooling in their latest Visual Studio. And, we get Avalon and XAML along for the ride, as well as the futures of C# 3.0 which takes a lot of ideas from the dynamic languages and puts them into a static structure (such as: var foo = new Bar(); and the relational/xml integration)

It is going to be an interesting couple of years, as all of these platforms mature, and take eachother on, trying to get mindshare!

Client Side: JavaScript is cool again

But what about Ajax? The battle for the client side is going to be just as hot as on the server. And they will even intertwine with eachother.

Firstly we have the big debate of how far Ajax is going to go. Is it a one hit wonder? or will it become a standard part of our toolbox and even just be called dhtml again?

As an Ajaxian, I obviously have my thoughts on this matter. But there is a lot of competition inside and outside of Ajax:

  • Flash/PDF: Adobe/Macromedia are a definitely force to be reckoned with. Flash is almost ubiquitous, and PDF is used everywhere. Now the companies are combined, what do they have in store for us?
  • Avalon/WPF/E/XAML: Microsoft announced WPF/E, which is a subset of XAML that will be ported on various platforms and available in many browsers. This means that you can build your rich application in the .NET set of tools, and have it run in Safari on Mac OSX. Impressive. When are we actually going to see this in a form that we can deploy to the real world?
  • HTML: How much do we want to work in the open (ish) world of HTML. A large group of developers do not want to jump into any monopoly, and will therefore want to stick to a more open environment. But, another set will just want to use the best tool to add business value. What will the split be?

JavaScript will play a big role in this war. JavaScript 2.0 offers big improvements, that many people will cheer for. Also, the same people who poo-poo’d JavaScript in the past have come to realise that it really is a great language. It may not be what they are used too (it uses prototype-based OO vs. class-based OO), but it is powerful and robust. There are some features missing, and a big question around libraries. JSAN and others are trying to build a CPAN for JavaScript. We also worry about the black box of the JavaScript VM in the browsers, and cross-browser bugs are truly real painful. Fortunately, frameworks like Dojo and Prototype are trying to help us out on that front.

We are also seeing that we need to take JavaScript from the former:

“That is just crappy code that the web dood View-Source’s and pastes into the web pages”

to the future:

“JavaScript also needs to be engineered, and is a first class citizen”

Thus we finally see more unit testing of JavaScript code, and professional ways of creating modules and namespaces for our code. We also see great advantages with features like E4X where XML becomes a native type.

JavaScripts increased popularity, thanks to Ajax (and Flash/ActionScript) has also drawn it into the server side. Mozilla Rhino gives you a quality Java-based approach, so why not use a cool dynamic scripting language for certain tasks on the server side? You don’t have to use JavaScript for everything, but it has its place, and that place is growing.

The Battles Join

This is where the battles are joining. We have JavaScript bleeding across the layers, and we have the need for server-side frameworks to support the new Web. It isn’t enough to generate simple HTML and be done with it.

Today’s frameworks need to be able to help us build Ajaxian components, and help us write this applications quickly and cleanly.

There are various directions that frameworks are going in here.

  • JavaScript Code Gen: Why not give you a simple macro that splits out the ugly JavaScript that you would have to write?
  • JavaScript Framework Code Gen: Spitting out low-level JavaScript is too much work. Many frameworks are writing on top of a higher level JavaScript framework like Dojo or Prototype. Now the code-gen is less, and you get the benefits of the rich functionality, browser compatibility, and visual effects available from these frameworks.
  • Tools and Widgets: Should developers even care if a piece of their page is Ajax or not? Some frameworks give you drag and drop editors that let you setup widgets or components. Some happen to be ajaxian. Some are not. Who cares?
  • Markup based: A lot of frameworks are giving us markup based solutions. That is one of the strengths of Microsoft Atlas, not the fact that they added support for $() etc. Are we going to want to build using markup or via programatic APIs?

Conclusion

It is hard to predict the winners of the new battles, and the losers will not die off totally, but it is an exciting time to be watching web development. The dynamic languages of Ruby, JavaScript, and PHP are making a big run, and people are realising that they aren’t just cheesy scripting languages that can’t be used. It’s time to take them serious.

We are going to start really working out what makes sense for usability on the web with rich interfaces. And, at the same time we will get simpler and simpler backend tools to make the generation of rich web experiences easier and easier.

I am looking forward to seeing this battle!

Sep 23

WebWork 2.2: Coninuations, Spring, Dependencies, and Books

Java, Lightweight Containers, Tech, Web Frameworks 84 Comments »

A lot of great news has come out of the WebWork team. Having used WebWork on a lot of projects recently, I am a big fan, as it is simple and gets out of your damn way! :)

Some of the great news:

  • Continuations: RIFE and WebWork have partnered around continuations (at least). WebWork now contains an early version of RIFE/continuations, and provides experimental support for continuations. This is so we can get closer to SeaSide if we want. Take a look at an example action:
    public class Guess extends ActionSupport {
    int guess;
    
    public String execute() throws Exception {
    int answer = new Random().nextInt(100) + 1;
    int tries = 5;
    
    while (answer != guess && tries > 0) {
    pause(SUCCESS);
    
    if (guess > answer) {
    addFieldError("guess", "Too high!");
    } else if (guess < answer) {
    addFieldError("guess", "Too low!");
    }
    
    tries--;
    }
    
    if (answer == guess) {
    addActionMessage("You got it!");
    } else {
    addActionMessage("You ran out of tries, the answer was " + answer);
    }
    
    return SUCCESS;
    }
    
    public void setGuess(int guess) {
    this.guess = guess;
    }
    }
    
  • Spring IoC by default: WebWork is working with the Spring team too, and Spring is now the default IoC container
  • WebWork in Action: "Where is the WebWork book?". It's finally here
  • WebWork Dependencies: WebWork uses Ivy, and has a nice view of its dependencies

Amazing work guys.

Sep 07

Putting configuration in annotations doesn’t mean “no configuration!”

Web Frameworks 1 Comment »

I read Matt’s posting on a new web framework called Stripes that is trying to make Java web dev simpler (aren’t they all these days? :).

What jumped out at me immediately is that the framework claims to have less configuration. Great.

Then you see the Quick Start Guide and see:

@UrlBinding(”/quickstart/Calculator.action”)
public class CalculatorActionBean implements ActionBean {

I don’t know about you, but that smells of configuration to me.

It is just HARD CODED in my Java source file, instead of in an EVIL XML configuration file :)

Rails’ convention over configuration builds the URL for you based on its own defaults, or your rules. Then you don’t have to put in any configuration…. else you get explicit.

Not that annotations are evil too…. just not a True Saviour to put all configuration into. Some of the annotation usage in Stripes is very nice.

Aug 24

WebWork 2: The sleeping giant

Tech, Web Frameworks 5 Comments »

Patrick Lightbody is talking about WebWork 2.2: JSR168 (Portlet) Support!.

Personally, I think that WW2 is a bit of a sleeping giant. It does a good job at hitting the niche that Rails hits wrt:

  • Close to HTML on the view… but your code is not tied to request/session/…
  • Simple, simple, simple
  • interceptors are nice and clean
  • Interesting Ajax support (and a lot more happening)

I hope that people take a fresh look at WebWork 2 and see the elegance, for those who aren’t into the component model.

Aug 16

Ted doesn’t get Rails

Java, Ruby, Tech, Web Frameworks 15 Comments »

Ted doesn’t get the Rails buzz after going to Dave’s Rails talk at No Fluff Just Stuff.

Firstly, you can’t say much for Ted wrt taste… I mean he is running that .NET blog software now ;)

Secondly, I think Ted hit the nail on the head and didn’t even realise it:

We found a greater need for configuration, more flexible and powerful execution models, and so on. In essence, as web apps got more complicated, the servlet/JSP space got more complex to match it. “With power, comes complexity; with complexity, comes power.”

I think the Java world took this waaaay to far. Abstractions upon abstractions.

We forgot that web frameworks ARE FOR THE WEB!!!

Before you look around we have JavaServer Faces, which “features” that you don’t just get to write out HTML. Sounds great on paper. I still hear people talking about how they will be able to just flip on a different Renderer and they will have a mobile application. Of course, in reality a mobile application is very different. You care about different things.

I want a web framework that lets me work with web technology (HTML is one of them ;), but gives me a nice clean way to do this.

Rails has a nice balance:

  • MVC is there. No model 1 JSP here.
  • Although MVC is here, you don’t have to learn struts html tags :)
  • All Ruby. Learn it, move on. No EL/JSTL/JSF-EL/OGNL/XML
  • Smart defaults, with the simple ability to plugin whenever you want (thanks Ruby)
  • Helpful wrappers on top of behaviour such as Ajax if you want it
  • Well thought out helpful code, such as flash

WebWork 2 does a good job of this on the Java side IMO. It gives you things that you need… but doesn’t make you have to learn a whole new world. Want components? Simple. Create some templates and you are done.

After spending time debugging a JSF application where JavaScript wasn’t output if your </f:view> was after the body tag…. it makes you really want to be Railing.

However, Rails is just a web framework. It has its issues like everything else, and isn’t a silver bullet. Often after learning about something fairly simple to get into like Rails you will be “huh that is it?”. In my opinion this is a very GOOD thing. Although, I do miss my IDE goodies :)

In my experience, I like to have simple tools which just work, but if the hardest part of your application is the web framework, you are lucky!

Jul 28

Facelets: JSF down right…. but what do you give up?

Java, Tech, Web Frameworks 470 Comments »

As soon as I saw Facelets I was a happy man.

I have always hated:

<h:form>
<h:dataTable value="#{widgetService.widgetDataModel}" var="widget">
<h:column>
<h:commandLink action="#{widgetService.delete}" immediate="true">
<h:outputText value="Delete" />
</h:commandLink>
</h:column>
<h:column>
<f:facet name="header">
<h:outputText value="Name" />
</f:facet>
<h:outputText value="#{widget.name}"/>
</h:column>
<h:column>
<f:facet name="header">
<h:outputText value="Description" />
</f:facet>
<h:outputText value="#{widget.description}"/>
</h:column>
<h:column>
<f:facet name="header">
<h:outputText value="Cost" />
</f:facet>
<h:outputText value="#{widget.cost}"/>
</h:column>
</h:dataTable>
</h:form>

And, moving back to just normal HTML with the odd jsfid attribute, class attribute, etc… felt at home.

If I was writing my own JSF web app, I would jump to use this view instead of the mess.

However, if you were a huge enterprise, and you were sold on “tooling”, then will this play in that world?

NOTE: Taming JSF 1.1 is an interesting article on JSF 1.1.

Jul 15

More Rails / Java Talk

Groovy, Java, JavaScript, Ruby, Tech, Web Frameworks 3 Comments »

Wow it keeps on coming (and ironically I am adding to it). This last slew of postings on Rails vs. Java came after Patrick Peak Rails: Where are the Implications for “No Deploying”?.

As soon as that came out we saw:

  • Dave Thomas: Rails and FUD
  • DHH: Letting cooler minds prevail
  • Jamis Buck: Application Deployment with Rails
  • James Duncan Davidson: Rails: Sandbox, Develop, and Deploy
  • Patrick Lightbody: It’s the tools, stupid!
    • The funny thing is that it is hard to know what we are really arguing about :)

      Scalability

      Can Rails scale? Sure. As Brian McCallister just said, scalability isn’t about a particular language.

      Do the different languages/platforms give you different implementation choices for scaling? Sure. Scaling with FCGI clusters is different to using Tangosol Coherence in a J2EE cluster.

      In some ways it is much simpler to scale a web app with shared nothing. However, on really huge enterprise systems (not web apps), tools *like* Coherence really help you out. It is nice to have the many levels and buttons available in your architecture.

      Again, Slashdot? Scales like a champ with Perl. There are a lot of huge enterprise Java systems that take in billions of transactions.

      So, conclusion? You can make both scale. You can make both run like a dog :)

      Tools

      Patrick has some good points in his post. I am not sure if he has checked out Textmate for doing Ruby development. It is quite nice indeed, although I do miss IDEA for some things (can’t beat its refactoring etc).

      With Ruby you really don’t need as MUCH tooling though. It is a nice concise language which doesn’t need as much scaffolding in the tools area. You can be very productive with Ruby – IDEA.

      However, IDEA really does do a good job of getting you closer to the productivity. I notice this a lot in Groovy world, and I am excited about GroovyJ.

      Tool support is only one leg on the chair though. There are many other components that matter as much, more-so, and maybe not as much.

      Refresh, Reload

      Tools can help get around the dev cycle that we have in Java, but we aren’t there yet. Patrick is correct in spotting the potential with dynamic languages on the JVM, where we could get the best of both. But we aren’t quite there yet.

      It is painful to jump to the Java world once you are used to hitting SAVE and refresh for every type of change (we can get far w/ JSP, etc etc).

      Both are beautiful, both can be ugly

      I love both platforms in many ways. I don’t like both platforms in others.

      • Java Dion: I wish we had the Ruby language on the JVM.
      • Ruby Dion: I wish Ruby had a nice VM to run on (the JVM would be really nice).

      Or maybe I will just do everything in JavaScript 2.0? ;)

      Oh, and David Geary had too much caffeine at the Rails Cafe? :)

Jun 08

Macromedia Flash Tool “Zorn” to Run on Eclipse

Web Frameworks 8 Comments »

Macromedia has joined the Eclipse Foundation. Who hasn’t joined it yet? Microsoft?

Wow.

I think this is a big step in moving Flash from “that way you put movies up on the web” to a full application development suite.

Developers have never liked the whole timeline. It is a scary beast from a different world. Now, we may move on….

But the big question: Will there be a command line SWF compiler? ;)