Declaring Your Logger - No Problem

I used to like the java specialists newsletter, most news used to be a bit challenging. Nowadays however the quality is lower. In the latest news, the author proposes to use the StackTrace to get the class name, in order to declare a Logger independently of any explicit reference to the class name.

While this is a clever hack, it still requires some code to be duplicated in every class, compared to Aspect/IoC approach. But was there really a problem with declaring loggers the usual way in the first place?

With modern IDEs, most people just create a template for the logger declaration line. Also, renaming MyClass to MyClass2 will rename MyClass.class to MyClass2.class automatically. Here is my template for Eclipse to which I assigned the short name log4j:

private static final Logger LOG = Logger.getLogger(${enclosing_type}.class);

Declaring Your Logger - No Problem

I used to like the java specialists newsletter, most news used to be a bit challenging. Nowadays however the quality is lower. In the latest news, the author proposes to use the StackTrace to get the class name, in order to declare a Logger independently of any explicit reference to the class name.

While this is a clever hack, it still requires some code to be duplicated in every class, compared to Aspect/IoC approach. But was there really a problem with declaring loggers the usual way in the first place?

With modern IDEs, most people just create a template for the logger declaration line. Also, renaming MyClass to MyClass2 will rename MyClass.class to MyClass2.class automatically. Here is my template for Eclipse to which I assigned the short name log4j:

private static final Logger LOG = Logger.getLogger(${enclosing_type}.class);

Very Quick Django Trial -> Bye Bye Django

I tried a bit django for one very simple thing, where django is not of much use, but it was a way to try it with something else than examples on the site.

Even if django templates features seem very good and very convenient when reading the docs (for example the extends keyword), I found out that the template system is very annoying. Firstly one has to learn another templating system. Secondly, and much more importantly, the debug facilities for templates are close to non existent. I have a better memory using ruby on rails templates (which are not the best either).

Java templates, based on Velocity, JSPs or JSF are much nicer to debug. PHP (which I consider an ugly language that can unfortunately often gets the job done) used to be crap at debugging, but with eclipse plugin phpeclipse it is much better these days.

I think templates play a very important role in web application development, and I am surprised that a framework with so many good ideas fails in reality (at least for me) because debugging templates is a pain. Hopefully it will become better one day, but until then bye bye Django.

Very Quick Django Trial -> Bye Bye Django

I tried a bit django for one very simple thing, where django is not of much use, but it was a way to try it with something else than examples on the site.

Even if django templates features seem very good and very convenient when reading the docs (for example the extends keyword), I found out that the template system is very annoying. Firstly one has to learn another templating system. Secondly, and much more importantly, the debug facilities for templates are close to non existent. I have a better memory using ruby on rails templates (which are not the best either).

Java templates, based on Velocity, JSPs or JSF are much nicer to debug. PHP (which I consider an ugly language that can unfortunately often gets the job done) used to be crap at debugging, but with eclipse plugin phpeclipse it is much better these days.

I think templates play a very important role in web application development, and I am surprised that a framework with so many good ideas fails in reality (at least for me) because debugging templates is a pain. Hopefully it will become better one day, but until then bye bye Django.

A Proof That JavaScript Sucks.

Google developed GWT.

Why would GWT be so well acclaimed if JavaScript was a good language. When you talk about GWT to someone (a developer preferably), the first reaction is often

"great I don't need to do any JavaScript".

I recently discovered another similar open source project, ZK. The first thing you can read on the website is

"ZK is an open source Ajax Web framework that enables rich user interface for web applications with no JavaScript and little programming."

If you compare that with how JRuby is (or Jython used to be) trendy, you will agree there must be a problem with JavaScript.

JavaScript is not bad at everything, for very simple scripting, it is quite decent, the recent inclusion of Rhino in the JDK 1.6 is useful anywhere you need simple dynamic behavior. But most developers obviously don't want to deal with it.

A Proof That JavaScript Sucks.

Google developed GWT.

Why would GWT be so well acclaimed if JavaScript was a good language. When you talk about GWT to someone (a developer preferably), the first reaction is often

"great I don't need to do any JavaScript".

I recently discovered another similar open source project, ZK. The first thing you can read on the website is

"ZK is an open source Ajax Web framework that enables rich user interface for web applications with no JavaScript and little programming."

If you compare that with how JRuby is (or Jython used to be) trendy, you will agree there must be a problem with JavaScript.

JavaScript is not bad at everything, for very simple scripting, it is quite decent, the recent inclusion of Rhino in the JDK 1.6 is useful anywhere you need simple dynamic behavior. But most developers obviously don't want to deal with it.

Building With Ant + Maven Antlib?

I discovered a new baby in the build world. Some open source projects use a combination of ant and maven. I thought you could vaguely use ant from maven. But I did not know of Maven Antlib that allows you to use maven2 from Ant. Why would you use Maven2 from Ant?

• because Maven2 requires to adapt your project to its standard hierarchy, or to have excellent Maven2 skills to create your own archetype for each existing project.
• because everybody knows Ant, but Ant does not manage dependencies well. Maven2 Antlib can be used just for that: managing dependencies.

I have to try that on a real project to see if it is really an easy and flexible approach, better than plain Maven2.

Building With Ant + Maven Antlib?

I discovered a new baby in the build world. Some open source projects use a combination of ant and maven. I thought you could vaguely use ant from maven. But I did not know of Maven Antlib that allows you to use maven2 from Ant. Why would you use Maven2 from Ant?

• because Maven2 requires to adapt your project to its standard hierarchy, or to have excellent Maven2 skills to create your own archetype for each existing project.
• because everybody knows Ant, but Ant does not manage dependencies well. Maven2 Antlib can be used just for that: managing dependencies.

I have to try that on a real project to see if it is really an easy and flexible approach, better than plain Maven2.

The Hibernate Network Proxy, A Dumb Idea.

A friend of mine had a good idea for a Java project named "hibernate proxy". I renamed it "hibernate network proxy" because hibernate proxies are already a well known concept among hibernate users (it allows lazy loading through a Java Proxy class).

The hibernate network proxy, is a way to use hibernate remotely, that is to proxy hibernate calls through TCP (or even HTTP) to another machine, that will execute the session.saveOrUpdate or the session.load, etc. calls and return the corresponding objects, serialize them and deserialize them for use on the client.

As most projects in my company involves several distributed services, this idea could have been potentially very interesting, allowing hibernate use in several services that would interact with a common service in charge of the db. It made me think about other standard patterns:

• This is not very different from the classical EJB session facade architecture, except we don't expose application functionalities, only hibernate stuff. In fact we don't want to expose application functionalities since they are not shared between services.
• This is very similar to Entity EJBs used without facade, remotely, the first kind of design we heard about when EJBs came out. This would actually be a good fit for doing this kind of stuff, amazingly. I never thought remote entity EJBs were of any real use. Unfortunately for our projects, we already have a messaging infrastructure, and I am not sure how feasible it is to change of EJB transport protocol. Seeing the complexity of something like IIOP, it looks like a dead end.
• This is a kind of Hibernate Second Level Cache, a cache with remote capabilities. The cache would proxy the request to the db service, and the db service would answer to that. This is a possible implementation that seems very flexible.
• Use a regular TCP connection to the DB, and hibernate in a standard way. Ok, it does not use our internal message bus, but it is so simple and standard. 

The last solution raises the most important question:

Why does it need to be proxied? 

To go through some particular port? -> use a port forwarder.
To go through HTTP? -> use HTTPTunnel.
You want Java only? -> use JHttpTunnel,there is even JSch for ssh

The Hibernate Network Proxy, A Dumb Idea.

A friend of mine had a good idea for a Java project named "hibernate proxy". I renamed it "hibernate network proxy" because hibernate proxies are already a well known concept among hibernate users (it allows lazy loading through a Java Proxy class).

The hibernate network proxy, is a way to use hibernate remotely, that is to proxy hibernate calls through TCP (or even HTTP) to another machine, that will execute the session.saveOrUpdate or the session.load, etc. calls and return the corresponding objects, serialize them and deserialize them for use on the client.

As most projects in my company involves several distributed services, this idea could have been potentially very interesting, allowing hibernate use in several services that would interact with a common service in charge of the db. It made me think about other standard patterns:

• This is not very different from the classical EJB session facade architecture, except we don't expose application functionalities, only hibernate stuff. In fact we don't want to expose application functionalities since they are not shared between services.
• This is very similar to Entity EJBs used without facade, remotely, the first kind of design we heard about when EJBs came out. This would actually be a good fit for doing this kind of stuff, amazingly. I never thought remote entity EJBs were of any real use. Unfortunately for our projects, we already have a messaging infrastructure, and I am not sure how feasible it is to change of EJB transport protocol. Seeing the complexity of something like IIOP, it looks like a dead end.
• This is a kind of Hibernate Second Level Cache, a cache with remote capabilities. The cache would proxy the request to the db service, and the db service would answer to that. This is a possible implementation that seems very flexible.
• Use a regular TCP connection to the DB, and hibernate in a standard way. Ok, it does not use our internal message bus, but it is so simple and standard. 

The last solution raises the most important question:

Why does it need to be proxied? 

To go through some particular port? -> use a port forwarder.
To go through HTTP? -> use HTTPTunnel.
You want Java only? -> use JHttpTunnel,there is even JSch for ssh