techno.blog("Dion")

Brian McCallister has started on a path of comparing Rails in a way that Strut’ters would get.

He is spot on that people have made a connection between:

Rails is easy. Look at the short demo video

and:

Rails is easy, which means it must no be flexible, or scalable, or …

However, I think Rails manages to be all of these things. The hooks are there for you to get your fingers dirty, while staying in the rails world. There are also many apps which are running with high load, and no scalability problems.

I am really looking forward to talking to Mr. Trails at TSSS, to see what his experience has been shoehorning a Ruby view on a Java platform.

As you look at the various languages, and platforms out there, you often see people discussing how much intelligence should go into the parser and runtime.

Java, for example, has a very simple syntax. The parsing stage doesn’t have to do and know too much (although Java 5 did add more).

Compare this to the other extremes. Lisp is incredibly simple. The MOP also makes it very powerful, and the user doesn’t ever really know if the ’standard’ operator they are using isn’t really a tweaked out version. The MOP analagy has been:

It is like juggling with chain saws

Perl on the other hand has to have a parser which is a lot smarter. Larry comes at it from a linguistic standpoint, and wants the language to do the right thing (even if it means having a tougher parser).

I think I follow that pattern. As always, there is a tradeoff, but I would much rather have a couple of guys work on a parser that does what I want, and have the many developers work on a level above of that. I want more expresiveness in my languages. I would hate to write a book with a stripped vocabulary, and a lack of context.

However, there is obviously a tradeoff. The parser will have more bugs. It will take longer to implement, it must be proven that it CAN be implemented, and the resulting code will have more ’style’ and can hence be harder to read.

On a selfish note, I don’t mind spending the time to be a ‘power user’. I spent the time to learn the keystrokes for vi and emacs, and I can do many tasks a lot faster there than anywhere else. As a power user you want the tools that allow you to express your ideas in as simple a way as possible.

So, it isn’t for everyone, but give me the smartest parser in the world, let me write as little as possible, and I will be happy ;)

I was a big fan of the Rails video which showed how simple it is to get up and running with the technology.

Now there is an 11 minute Trails video, which walks through a ‘Recipe’ sample application:

Well, I got the video done. I created the Recipe application from the onLamp.com article in 10:53 seconds, and that

The 2nd Early Review Draft for EJB 3 has been released. Apart from changes such as splitting the doc into two (persistence + ‘other’), the main addition is the fact that EJB now has interceptors. Something that people have been wanting for a long time.

Currently the draft states support for Session and Message-Driven Beans, and the spec questions the need for support in Entity bean business methods.

The interceptor module is based on AroundInvoke methods:

public Object methodName(InvocationContext context) throws Exception

The InvocationContext has methods such as:

getBean()

getMethod()

getParameters()

getEJBContext()

Map getContextData()

proceed()

Good to see something like this making it into the spec. I will be even more excited about EJB 4.0 when it is an aspect based set of concerns ;)

Read more in the EJB 3.0 Docs

I was happy to see that Coherence 3.0 pre-release (build 302) is now available.

There are a few major tweaks for 3.0. I am really interested in the new JMX support. It will be great to popup a JMX browser and watch what is going on in my clustered caches:

Coherence Management Framework

Coherence 3.0 Management Framework introduces the capability to monitor virtually all cache settings and statistics for Coherence caches and services at runtime utilizing the standard JMX interface. Coherence Management Framework makes it possible to view and manage Coherence operational parameters and cache statistics through any JMX-based client console product or development framework. For more information please refer to the “Managing Coherence

Jim Weirich has got a public list on Things a Java Programmer Should Know About Ruby.

This list does tell you a lot, although there are a few politically charged ones:

• Fixed what’s wrong with Perl
• Fixes what’s wrong with Python
• It’s super productive (like Perl, Python and Smalltalk)- maybe 5-10x Java.
• Is a lot like Smalltalk, but doesn’t look as funny
• Is a lot like JavaScript, but more OO and more for full app development

Try to ignore those a little (no matter how you feel about any of them) and stick to the technical side.

Personally, I find myself smiling more when I write Ruby code. It just fits me well.

And I love items such as:

while line = gets do
puts "Found: #{line}" if line =~ /start/ .. line =~ /end/
end

The core items that help me out are:

• Duck Typing: Thinking in terms of behaviour, versus strict typing via Class heirachies really helps me
• Closures: I go on and on about this one I know. I just love the clean code that comes out of it.
• Dynamic Typing: I just don’t by in to the static typing way. Although I see some benefits, it gets in the way too much. And, as Dave Thomas puts it… Java isn’t fully baked in this area as if it was, there would be nice need for ClassCastExceptions :)

Now, there are items in other languages that are also gems. I definitely miss IntelliJ when writing Ruby code :)

TheServerSide communities are now running on Tapestry on the front end, and Kodo JDO for the data access.

We had known for awhile that it was ready for a change, and it was an interesting experience choosing what we wanted to port TSS over too.

There are many great web frameworks, and data solutions, but we definitely ended up happy with what we got.

The port was done in record time, in no part thanks to having Howard Lewis Ship on the team. If you are ever doing a Tapestry project, you owe it to yourself to bring him in for a bit. Not only does he obviously know Tapestry inside and out, but he is just a top class developer which great ideas!

Looking at the before and after version of TheServerSide is very interesting. Now TSS has a great, component-based version which is easy to extend. Before, it was always a fight to change / add anything.

It also doesn’t hurt that the site is faster and more stable than ever before. Kodo JDO has been top notch on that scale, and it has the solid Tangosol Coherence under the scenes as the distributed cluster technology.

Read more: How TSS Converted to Tapestry

I always enjoy the Dr. Heinz Kabutz Java Specialists’ Newsletter .

He often seems to find the most bizarre corners of Java and the JVM.

A long time ago he showed how he could get:

(”hi there”.equals(”cheers !”)) == true

Now he shows how auto-boxing allows him to cheat the flyweight pattern of: Integer valueOf(int) (and for the other primitives).

Each class seems to keep a cache of its values, and if a security manager isn’t setup, we can dip into this cache and make some changes via:

try {
Class[] classes = Integer.class.getDeclaredClasses();
for (Class clazz : classes) {
if (clazz.getName().endsWith("IntegerCache")) {
Field cacheField = clazz.getDeclaredField("cache");
cacheField.setAccessible(true);
Integer[] cache = (Integer[]) cacheField.get(null);
for (int i = 0; i < cache.length; i++) {
cache[i] = new Integer(0);
}
}
}
} catch (Throwable e) {
// we silently pretend we didn't want to destroy Java...
}

Drew Davidson, of OGNL fame (amongst other), has written an OGNL-based property configurer (BeanFactoryPostProcessor implementor) that evaluates OGNL expressions in <value>, <map> and <list> entries, etc in the Spring configuration.

I get to use OGNL whenever I am working on either of my favourite web frameworks for Java: Tapestry and WebWork2.

It is one of those small languages that does one thing, and does it really well. It is a lot more powerful than the EL.

So, I am excited to see the like of OGNL, and Groovy, for configuring and wiring my components together. Thanks for this work Drew!

From time to time the question has come up:

Do we need to have any standardization in the AOP space?

Of course, the first question that comes to mind, is what do you want to standardize?

The AOP Alliance got together several years ago, and gives you an API for dynamic proxy impls to play nice together (you can reuse advice and such with Spring AOP, dynaop, AspectWerkz, etc). However, the effort has stalled to some extend (maybe because it has done its job).

I think people wanted standardization because they wanted to be able to plugin different AOP systems like dynaop/Spring AOP/AspectWerkz/AspectJ. But we haven’t been in a place to do that yet, as the different platforms were really very different. We also don’t want to restrict to a low denominator too early, as we need to allow different frameworks to experiment and push things.

The AspectJ and AspectWerkz merger may well be the end of standards talk. When AspectJ 5 comes out it will be a top solution. We will have the full power of the AspectJ semantic model, yet for those who want it, they can use a Java/annotations view of things versus the AspectJ language.

AspectJ 5 will become the absolute de facto standard. I think it will be great for AOP as people will be able to get stuck in, and move on to more interesting problems, such as practices for using AOP, and even the holy grail of reuseable, REALLY USEFUL aspects :)