techno.blog("Dion")

Wow. It is finally here. It really has been “a long road” as Sun said in their JCP ballot notes. Now it is here, is it enough. A lot of heavy hitters have gotten behind Faces (Oracle, Sun, etc) but there has been a mixed reaction in the community. Some people don’t see the need for a layer like this, some see a need but don’t think Faces is “it”, and some think that this is going to be THE way to do web development from now on.

I definitely think we have a ways to go when it comes to being productive in web development. I have seen far too many projects that spend mind blowing amounts of time on the “web layer stuff” compared to the business problems themselves.

We also have to remember that although this is a standard, it is only 1.0. It is not the holy grail. Remember EJB 1.0?

It *is* good to get some good tool support, and work on making the web tier a better place. I hope Faces spurs on the niche. Good luck, and the next few months will be interesting.

Discussion on the JSF 1.0 release

JavaServer Faces 1.0 has been released, but why does it matter?: Kito Mann’s editorial on the new release from JSFCentral.

Whenever I get together with Ted, the group we are in somehow gets onto the topic of EJBs. We got around to it this time as we had heard the CTO of Orbitz discuss their Service Oriented Architecture, and how they use EJBs. Almost sensing that people would gasp, and think that he must be a bad bad CTO, he clarified that they used EJB for transaction processing.

Fancy that, a use for EJB. Ted and I always end up with “EJB is good at TP and should stick with that”. It isn’t good at persistence, and shouldn’t probably be a distributed object system. EJB is very good at doing the right thing with respect to transactions. The containers are mature, and know how to enlist correctly…. and it all “just works”.

So, as time goes on and I ask myself “when would I ever use EJB in a project”, I find myself justifying it if I was building a truly enterprise system (which is 1% of the total systems that are built?) and I wanted it to handle my TX throughput. In this scenario I could be happy enough using Stateless Session Beans, and Message Driven Beans. For persistence I would not touch Entities with a barch pole, but would opt for transparent persistence (JDO/Hibernate).

The lightweight containers don’t seem to be quite there wrt efficiently doing the right thing with distributed TX, but I am pretty sure that they will catch up. In fact Ron Bodkin (AOP guru) has worked on some nice Aspects that can handle things quite nicely… so this could be promising for the future.

Bottom line? EJBs have a place…. but should focus on the E, and yeah, they aren’t for the majority of projects. I hope that EJB 3.0 gets this, and starts dealing with the requests that developers on these huge systems need, and don’t just slap on some JSR 175 metadata, claim that EJB is easy, and sing a song. If AOP really kicks into gear, I think it would be fun to see EJB be a group of standards around various service aspects.

And don’t get me started on the fact that messaging systems don’t seem to be used nearly enough on projects!

It is a good time to be a Java developer. We have the new IDE releases of IDEA and Eclipse, new frameworks like dynaop, WebWork 2, Chrysillis and more. Then we have the beta release of JDK 1.5. A lot of fun stuff!

I was surprised to see an open source (LGPL) Java clone of iTunes has been put up on SourceForge.

JTunes uses JRendezvous from strangeberry and javalayer as mp3-player from javazoom. (The DAAP-part is from the iLeech Project.

Ahh, so now when I really want to hack some scripts, but have all of this Java code on the business tier, I can just use Inline::Java :) I can play in the loosely coupled world of Perl on the script side… and have all of the benefits of the well designed Java business objects :)

Or I could use Jython. Or BeanShell. Or …..

Read: Bringing Java into Perl

#!/usr/bin/perl
use strict; use warnings;

use Inline Java => <<'EOJ';
public class Hi {

String greeting;

public Hi(String greeting) {
this.greeting = greeting;
}

public void setGreeting(String newGreeting) {
greeting = newGreeting;
}

public String getGreeting() {
return greeting;
}
}
EOJ

my $greeter = Hi->new(”howdy”);
print $greeter->getGreeting(), “\n”;

There is definately a group of people that are a bit sick of Ant. This is a general “I don’t want to code in XML” problem too. Some are making the leap to Maven, with all of its b# builds. Others are just going back to the basics.

Philip Crow has just added Java::Build to CPAN.

He writes:

“Java/Build version 0.01
=====================

In my shop, we grew tired of using Ant for builds. We wanted to script,
and as the O’Reilly book on the subject points out at length, Ant is not
a scripting language. We wanted variables, loops, conditionals, and
subroutines, to name a few things. Eventually we decided to move to a
Perl based build system. This is the result of that work.

Ant provides one essential feature:

It uses only one JVM

In our builds, this issue is only important for compiling. All of the
other tasks are uncommon enough that starting a new JVM for each one is
not prohibitively expensive. (It is possible to add to Java::Build::JVM to
use its JVM for additional tasks, but we haven’t needed to yet.)

By using Java::Build::JVM, you get one JVM which you can keep using
for compilation throughout your script.

Java::Build::Tasks provides some useful helper functions. None of them
are essential, but they seem to make our scripts easier to write and more
consistent. The tasks currently include: jar, signjar, read_prop_file,
update_prop_file, build_file_list, and what_needs_compiling (the later uses
time stamps to decide which class files are missing or stale).”

Apache has created Apache Geronimo (for now), a J2EE implementation that they “promise” will run the TCKs from Sun! The most interesting part of this is who they have gotten involved in the project:

(the projects in parens are projects where they commit)

* Bruce Snyder (Castor JDO)
* Dain Sundstrom (JBoss)
* David Blevins (OpenEJB)
* David Jencks (JBoss)
* Geir Magnusson Jr. (Apache)
* Greg Wilkins (JBoss/Jetty)
* James Strachan (Apache)
* Jan Bartel (JBoss/Jetty)
* Jason Dillon (JBoss)
* Jeremy Boynes (JBoss)
* Jim Jagielski (Apache)
* Jules Golsnell (JBoss/Jetty)
* Richard Monson-Haefel (OpenEJB)
* Remigio Chirino (JBoss)
* Simone Bordet (mx4j)

That is one great list, and if they work on it, it must succeed right? Even if Apache is running it? (heh just kidding!).

It will be interesting to see how they package everything together (how they will use the other Apache projects… like Tomcat, James, etc).

I wish them all well, and look forward to a good J2EE implementation some time soon!

Go to the TSS thread that has the emails that have been sent out, which explain a LOT of the thought behind this.

What do you think? Comment here and at TSS!