techno.blog("Dion")

There has been a lot of discussion spirred on the Apache Project Harmony announcement.

It even gave Hani some ammo other than that from the TSS Symposium :)

I think I know why they are doing this though. It isn’t to do with opensource, nor making a better JVM, or anything like that.

It is all about the Apple!

I polled the group that have put their name to the petition at Apache, and they are all Mac users. These poor people are so sick of the Apple support that they want to write something decent themselves so they aren’t behind the times all the time ;) ;) ;)

I have had an absolute ‘duh’ moment. I am a Ruby fan, and keep pinging JRuby to see if it is ready for prime time, and it never is (YET!). I have also talked with Microsoft about Ruby.NET.

I have written Python code in my past, but it was sandwiched between Perl and Java, and was used at first due to the very nice embedable API (embedding Perl was a nightmare for example). And, then I have moved on to Ruby/Groovy for my scripting needs. So, partly due to timing, partly due to FEEL, Python has been overlooked (as has PHP).

However, it turns out that Python is an obvious choice for a dynamic language that is fairly ubiquitous:

Not only can you get it on unixen, Windows, etc… but it runs on the JVM and CLR!

JPython

JPython has always been out there, but it seems to have picked up more steam recently (anecdotaly). We do have the strange combining of the worlds, and deciding whether to use python APIs vs. Java APIs, which depends on whether you are looking to run on the Java platform and just use a scripting approach here and there, of if you want a scripting language on a whole set of platforms (e.g. reusing your .py all over the shop).

IronPython

It seems that the Python community hasn’t been happy with how Microsoft has gone quiet until a recent IronPython release. Jim Hugunin is a great bloke, and I have no doubt that things will change and he will be able to break through the MSFT beauracracy.

With a solid IronPython, JPython, and CPython, you now have a very compelling dynamic language!

If you can put up with self ;)

And, there is also word that a new web framework named spyce is going to try to do what Rails has done for Ruby.

Imagine Maven talking to Jelly talking to Ant talking to Groovy :)

Jeremy Rayner contributed a nice Groovy Ant task, which we can piggy back on in Maven.

Guillaume Laforge put in the magic to make sure that the Maven POM is injected into the scripting engine, so you can play with $pom:

<project default="groovy" xmlns:ant="jelly:ant">
<goal name="groovy">
<ant:taskdef name="groovy" classname="org.codehaus.groovy.ant.Groovy" classpathref="maven.dependency.classpath"/>
<ant:groovy>
println pom.eachPropertyName{ println it }
println pom.name
</ant:groovy>
</goal>
</project>

It would be cool to be able to <ant:groovy script=”….”/>, or to write tags IN Groovy itself.

Of course, with m2 we will be able to write plugins with Groovy (as well as BeanShell and the like).

Brett Porter also talked about his addition to Maven to support CVS/SVN as a Maven repository itself. I personally am fine with using a traditional repository, where the http://….. is a SVN view itself, but I do hear people asking for exactly what Brett has implemented. Kudos Brett for doing this even though you won’t be using it yourself!

It was good to hear that IntelliJ IDEA 5.0 is coming soon.

I am excited about some of the features like native SVN support etc, but to be honest what I really am into, is the JavaScript support.

At the moment, Visual Studio (Whidbey) has an awesome HTML/JavaScript story. You can select what browsers/standards you want to target and completion filters to the features supported by your set.

Now I won’t have to leave the world of IDEA to get my JavaScript support!

A group of people were talking at No Fluff Just Stuff, and Richard Monson-Haefel brought up using AOP to manage multiple products from one code base.

It can actually make a lot of sense. Imagine having a software product that has:

• Express: A bunch of enterprise features are disabled
• Standard: fully featured, but none of the hard core enterprise features
• Enterprise: Enhanced enterprise features

Then there could be trail editions of the various products.

30 day aspect

To handle a trial period, an aspect could be woven into the code to handle all of the crippling.

For example, WebLogic used to let a few IP addresses to hit the server only. An aspect could track the incoming IPs and block after the allowed number come in (of course, some people just put WLS behind a proxy to trick it! Lots of 127.0.0.1 comes in ;).

This could be reused among all editions of the product.

Throttling aspect

Let’s say the Express edition only allows X concurrent uses of feature Y. A simple set of aspects could throttle the features.

Additional behaviour

Additional enhanced behaviour could get weaved into the core.

IBM Cloudscape vs. Apache Derby

There are rumours that IBM uses this technique already. With this, they can add in the enhanced transaction support and other features that make Cloudscape from Derby.

Lucene is one of my favourite opensource packages. I often find that I do need to ’script’ it so to speak, and Jeremy Rayner has shown how Groovy fits in.

He has taken some examples from Lucene in Action, and made them Groovy.

Very nice.

Nick Lothian has put up a 0.1 release of a nice Search Engine wrapper API called Argos.

About Argos

Argos is an open source (Apache licenced) Java library for accessing the search APIs provided by internet search engines. It provides a consistent, extensible and easy to use API, while supporting advanced features such as a paged request model and a simultaneous search across multiple engines.

Argos currently supports the following search engines:

• Blogdigger
• Del.icio.us
• Feedster
• Google
• Google Desktop Search
• MSN Search
• Technorati
• Yahoo

Here is an example of running a simultanous search on MSN and Blogdigger:

List<Searcher> searcherList = new LinkedList<Searcher>();
searcherList.add(new MSNWebSearcher());
searcherList.add(new BlogdiggerWebSearcher());

SimultaneousSearcher searcher = new SimultaneousSearcher(searcherList);

Iterator<SearchResult> it = searcher.search("Java");
while (it.hasNext()) {
SearchResult result = it.next();
System.out.println(result.getTitle() + " Address: " + result.getAddress());
}

A nice simple API, and one consistent one for a group of search engines.

It was cool to read from Rob that Spring Modules 0.1 has been released.

After a few weeks worth of effort in setting up the project and getting our initial codebase started, we have finally released Spring Modules 0.1.

This release includes:

• Spring-style configuration for OSWorkflow
• Support for JSR-94 rules engines
• HiveMind integration
• Commons Validator support migrated from Spring sandbox

You download the release from the home page.

As Spring has grown so fast, it needed a way to have modules, else how could it be called Lightweight? :)

0.1 has some useful stuff already, and I am sure there is a lot in the works to move over to that playpen.

Cedric has responded to the article on TheServerSide, Implementing Object Caching with AOP.

He discusses the coupling issues that are intrinsic to any of these crosscutting problems.

The nice thing about AOP, is that it gives you the tools to add to the balance.

You can choose to:

• Use a marker based approach (@annotation / marker interface / naming convention in methods [normally bad])
• Have a more complicated policy defining a pointcut in code (e.g. List around(String productGroup) : getInterestRates(productGroup) {)
• Define a DSL in some form to handle the configuration

At the end of the day, these are all the same in more ways than they are different. Cedric says:

It should be configurable externally. You don’t need AOP to branch conditionally and disable (or alter) your caching logic at runtime. Most of the EJB and web containers that I know have been providing this kind of functionality in XML files for quite a while.

This is an example of a DSL. In this case, there is a very formal way to specify SOME form of caching for EJBs. It is very limited, but it is well specified.

A lot of the time people want a lot more control (and not be forced to use EJB ;), and that is where the other options come in. You could create your own XML definition which powers the caching configuration (an Aspect could grok that), you can use annotations if you think it makes sense to declare the configurability of the caching IN the area of the code, or you can modularize it completely by NOT having this, and having it all in an external aspect. At this point your code doesn’t know about the caching cross cutting concern.

In my opinion, there is no RIGHT answer for all of your needs. As with all these things, depending on your use cases, you will find the right balance.

We added Tangosol Coherence to the TSS code way back, and we only needed caching in the form of DATA caching. Thus, we could add it to our persistence layer, in one simple place, and the AOP approach may well have been overkill here.

But there are many other types of caching, and I think an AOP modularization of this concern makes a lot of sense.

Alex Vasseur (of AspectWerkz/AspectJ 5) has written a thorough piece on EJB 3 and AOP: the EJB interceptor dilemna.

He delves into issues with the EJB 3 specification of interceptors (wrt AOP), for example, having to specify interception via:

@javax.ejb.Interceptor(”test.ejb3.MyInterceptor”)

He also complains a little about current preview implementations:

After having a look at JBoss EJB 3 and OracleAS EJB 3 previews, I was even more disapointed. Both of them are using a reflective based approach to invoke the interceptors. This means that the performance of the interceptor will be bad, and that a Heisenberg effect will be inevitable and actually fairly big (no wonder that ones will use interceptor to gather performance metrics and thus as soon as you observe the bean, you are observing a different things than what actually happens).

Ones may say this is a microscopic view. It is. But when thinking about EJB 2 stories in the past a sound idea would be to make sure we don’t waste resources where we can avoid it. And thinking about JBoss history around AOP, that’s rather suprising that the EJB 3 interceptors are not cleanly integrated in their AOP framework. I personnaly consider that we have enough technology around to make it far better, and far more consistent with AOP. Given the impact that AOP will continue to have, ones would better figuring out how to do that now with EJB 3 – assuming that EJB 3 succeeds.

He then spent 1 hour IMPLEMENTING the spec itself using the AspectWerkz AOP container, which is pretty damn impressive IMO.

Alex is even kind enough to put in some thoughts on the spec:

There are some odd things in the 3.5 section of the JSR-220 that I have spot:

• (sect. 3.5.1) an interceptor class or EJB can only have one single @AroundInvoke method (advice) in it, and its signature is (sect. 3.5.4) “@AroundInvoke Object someNameOfYourChoice(InvocationContext ctx) throws Exception”. Why limitating that to having one single method in the interceptor class or EJB (sect. 3.5.1). My guess is that it is tied to the fact that precedence between advice would then be harder to define in the spec without new semantics. Then one might wonder why an interceptor is not defined as an interface with one single method “intercept(…)” that the EJB could implement as well. Having this interface would suppress the need for @AroundInvoke which sounds like an annotation overuse (unless it is a door open for vendor extension as I will do below..). I’ll be interested in EG feedback on that topic, especially in regards of the first limitation.
• interceptor components life cycle is unspecified but stateless. That sounds like a very important and powerfull concept of AOP (especially AspectJ) that has been left aside. It is probably an interesting door to provide vendor specific extension ie thread safe interceptor, per bean class interceptor, per bean instance interceptor, per application interceptor etc (but then interceptor component may not be stateless anymore.)
• (3.5) an interceptor intercepts all business method (or MessageListener methods for MDB). This means that every interceptor will be poluted with a code snip like “if (invocationContext.getMethod().getName().equals(”doSomething”)) …” ie ones will have to write sort of a pointcut in a very loosy way while AOP allow us to write that in a neat way (and further, a way that tools can easy understand to spot which method is intercepted by what).
• javax.ejb.InvocationContext is tied to EJB. What will happen when interceptors will end up somewhere else ?

Fortunately, the implementation exposed in this article addresses those issues nicely from a vendor specific extension perspective.

Awesome stuff Alex.