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

Workaround When Eclipse Fucks Off With CVS

Until recently, I always found Eclipse CVS support to be excellent. The synchronize view was really a big plus to do clean commits, without forgetting any file.

But I have encountered several problem with Eclipse 3.2+:

On one project, it keeps putting the build directory into CVS, and I can't find how to change that setting. Each time I open the project I have to change the CVS/Entries file.

On another, where I have lots of files in, Eclipse delete some of the files (checked in CVS) regularly, although not often. It won't retrieve them back again from CVS. It seems to be the same files each time. I have no clue why.

The diff sometimes tells me the whole file has changed while there is absolutely no change.

I could not make the merge work. It kept on complaining about some parameters.

And now the workaround for all those cases:

The good old CVS command line.

I never remember how do to a merge with the command line, so I each time go to google and read this merge example page. Here are the very simple steps if you are in a branch and want to merge:

1. cvs update -A mypoem.txt (use head as local repository)

2. cvs update -j release-1 (merge release-1 changes into local repository)

3. cvs update mypoem.txt

4. cvs commit mypoem.txt

Workaround When Eclipse Fucks Off With CVS

Until recently, I always found Eclipse CVS support to be excellent. The synchronize view was really a big plus to do clean commits, without forgetting any file.

But I have encountered several problem with Eclipse 3.2+:

On one project, it keeps putting the build directory into CVS, and I can't find how to change that setting. Each time I open the project I have to change the CVS/Entries file.

On another, where I have lots of files in, Eclipse delete some of the files (checked in CVS) regularly, although not often. It won't retrieve them back again from CVS. It seems to be the same files each time. I have no clue why.

The diff sometimes tells me the whole file has changed while there is absolutely no change.

I could not make the merge work. It kept on complaining about some parameters.

And now the workaround for all those cases:

The good old CVS command line.

I never remember how do to a merge with the command line, so I each time go to google and read this merge example page. Here are the very simple steps if you are in a branch and want to merge:

1. cvs update -A mypoem.txt (use head as local repository)

2. cvs update -j release-1 (merge release-1 changes into local repository)

3. cvs update mypoem.txt

4. cvs commit mypoem.txt

Maven: Game Over, Try Again

I am writing only as a newbie on Maven2. I tried to use it several times on small projects, but each time I found out that the time involved to make it work with an existing project was too much a pain in the a**. When confronted to very simple hierarchies that are not the standard of the documentation, I was a bit lost on how to arrange things, except changing the whole hierarchy to adapt to Maven.

Also on small scale code, Maven requires you again to adapt your project to it and it will make your small code look like an important enterprise project. For example if you want to build a small test that can be executed as a server (with one particular class), as a client (with another class), or as a servlet, using one or two other common classes, Maven requires at least 3 source hierarchies (with src directory).

I think it is not only because I know ant (much) better that ant proved many times to be quite flexible, and I have never been on a project where switching from Makefile to ant was a problem. I am not an ant fan. I have a preference of code over XML that ends up here and there being like code, in a much less flexible way. However Ant, as I said, is flexible. One can always use the good old scripting languages (javascript, beanshell, etc.) to define new tasks, and therefore bypass any inflexibility of the original design.

Still Maven2 has plenty of very good stuff, especially for more normal projects. It provides versioning, central repository and dependency checking for you. It is probably a good idea to use it rather than bad ant scripts, or, even worse, old Makefiles. Also Maven2 hierarchy conventions are not stupid, it is just not fitted for quick and dirty stuff.

Maven: Game Over, Try Again

I am writing only as a newbie on Maven2. I tried to use it several times on small projects, but each time I found out that the time involved to make it work with an existing project was too much a pain in the a**. When confronted to very simple hierarchies that are not the standard of the documentation, I was a bit lost on how to arrange things, except changing the whole hierarchy to adapt to Maven.

Also on small scale code, Maven requires you again to adapt your project to it and it will make your small code look like an important enterprise project. For example if you want to build a small test that can be executed as a server (with one particular class), as a client (with another class), or as a servlet, using one or two other common classes, Maven requires at least 3 source hierarchies (with src directory).

I think it is not only because I know ant (much) better that ant proved many times to be quite flexible, and I have never been on a project where switching from Makefile to ant was a problem. I am not an ant fan. I have a preference of code over XML that ends up here and there being like code, in a much less flexible way. However Ant, as I said, is flexible. One can always use the good old scripting languages (javascript, beanshell, etc.) to define new tasks, and therefore bypass any inflexibility of the original design.

Still Maven2 has plenty of very good stuff, especially for more normal projects. It provides versioning, central repository and dependency checking for you. It is probably a good idea to use it rather than bad ant scripts, or, even worse, old Makefiles. Also Maven2 hierarchy conventions are not stupid, it is just not fitted for quick and dirty stuff.

How JDepend Changed My Java Packaging

One important feature of Java language is the package keyword. It helps a lot in modularizing your code. But how exactly one should use it is not that clear.

I have been on projects where 100s of classes are in a same package and more often where you have packages for every 2 classes. Often, packages are chosen so as to split functionalities. But often as well, people are packages maniacs and create way too many of them, because they want to sort things out, not necessarily applying a consistent logic. For example, I am sure many of you have seen the "blahblah.exceptions" packages where you dump exceptions classes.

Without any precise intention for packages, you encounter quickly cyclic dependencies in your project, and your build system becomes overly complicated. Then you try to remove cyclic dependencies, not by using the package keyword better, but by building jars differently (=ugly jars) and "refactoring" a bit.

I fell myself in many of those traps. Fortunately I stumbled on my way on JDepend package analysis program. At first I wondered why JDepend calculated dependencies between Java packages and not between Jars, as in your project what matters is jar interdependencies. After using it regularly, first for the fun of trying not to have cyclic dependencies in my Java packages - the green light effect (I wanted my green light on my project), I understood much better its interest. I now make Java packages that are much more meaningful. They not only separate functionalities, but also create excellent modularity. Building a project is very easy, reusing parts of it is very clear. If one needs to split a jar in a project, it's very clear how to split it (by Java packages). And I find that in the end my packages make much more sense.

Placing a class in the right package is most of the time not difficult, especially for experienced programmers. But now and then, with JDepend, I find mistakes. Correcting those mistakes regularly, when it's just about one or two classes is quick and easy. Correcting them on a project where dependency analysis was never done is a nightmare.

Now I don't really care about JDepend metrics about abstractness and instability so much, I did not find any good use of them. But JDepend (or a package dependencies checker) really is an essential program for good Java development.

How JDepend Changed My Java Packaging

One important feature of Java language is the package keyword. It helps a lot in modularizing your code. But how exactly one should use it is not that clear.

I have been on projects where 100s of classes are in a same package and more often where you have packages for every 2 classes. Often, packages are chosen so as to split functionalities. But often as well, people are packages maniacs and create way too many of them, because they want to sort things out, not necessarily applying a consistent logic. For example, I am sure many of you have seen the "blahblah.exceptions" packages where you dump exceptions classes.

Without any precise intention for packages, you encounter quickly cyclic dependencies in your project, and your build system becomes overly complicated. Then you try to remove cyclic dependencies, not by using the package keyword better, but by building jars differently (=ugly jars) and "refactoring" a bit.

I fell myself in many of those traps. Fortunately I stumbled on my way on JDepend package analysis program. At first I wondered why JDepend calculated dependencies between Java packages and not between Jars, as in your project what matters is jar interdependencies. After using it regularly, first for the fun of trying not to have cyclic dependencies in my Java packages - the green light effect (I wanted my green light on my project), I understood much better its interest. I now make Java packages that are much more meaningful. They not only separate functionalities, but also create excellent modularity. Building a project is very easy, reusing parts of it is very clear. If one needs to split a jar in a project, it's very clear how to split it (by Java packages). And I find that in the end my packages make much more sense.

Placing a class in the right package is most of the time not difficult, especially for experienced programmers. But now and then, with JDepend, I find mistakes. Correcting those mistakes regularly, when it's just about one or two classes is quick and easy. Correcting them on a project where dependency analysis was never done is a nightmare.

Now I don't really care about JDepend metrics about abstractness and instability so much, I did not find any good use of them. But JDepend (or a package dependencies checker) really is an essential program for good Java development.

You Know IOException? Think Again!

I was amazed today to find out that there was no constructor IOException(String, Throwable) or IOException(Throwable) in JDK1.4 and JDK1.5. It is finally in JDK1.6, I can't believe it took Sun that much time to change that.

So the workaround is:

IOException ioe = new IOException("message");
ioe.initCause(e);
throw ioe;

It can also be written as:

throw (IOException) new IOException("message").initCause(e);

It is not a major problem, but still. We can all thank the guy who reported that as a bug to Sun in 2004.

You Know IOException? Think Again!

I was amazed today to find out that there was no constructor IOException(String, Throwable) or IOException(Throwable) in JDK1.4 and JDK1.5. It is finally in JDK1.6, I can't believe it took Sun that much time to change that.

So the workaround is:

IOException ioe = new IOException("message");
ioe.initCause(e);
throw ioe;

It can also be written as:

throw (IOException) new IOException("message").initCause(e);

It is not a major problem, but still. We can all thank the guy who reported that as a bug to Sun in 2004.

Good Software Books - 2006 version

Here is an update of the most interesting software books I found interesting. I already made such a list in 2005:

• Object Oriented Software Construction, 2nd Ed, by Bertrand Meyer. This made me understand why OOP is important, what is important in OOP and why it is still relevant. It contains lots of important guidelines you can apply to better design programs. One famous quote is "Real systems have no top". Code Complete (Microsoft Press) covers some of the same ideas as Meyer's book, and some more pragmatic issues that arise in software projects ("measure twice, cut once"). I also liked the chapter on "table driven design".
• Concurrent Programming in Java, Second Edition, by Doug Lea: there is all you need to know about programming in a multithreaded environment in it. The chapter on synchronization should be a must read for every Java developer.
• Design Patterns by the GoF: simply the best presentation of most common design patterns. I have a glance on it once in a while.
  
• Artificial Intelligence through Prolog, by Neil C. Rowe (Prentice-Hall): if you don't remember much about Prolog, it's a good book. It details how Prolog interpreters work.
• File Systems Forensic Analysis, by Brian Carrier (Addison Wesley): everything you need to know about disks and file systems, every trick to recover lost data. To go more in depth into file systems theory, you can read the free Practical File System Design with the Be File System from D. Giampaolo, the creator of BeFS.
  
• Mind Hacks (O'Reilly): you probably already bought that one. Not about software, but excellent.
  
• Practical Issues in Database Management by Fabian Pascal (Addison Wesley): short but concise book on relational database theory. F Pascal is of CJ Date school of thoughts, "null are evil". You don't need to read it if you have read any other similar book (by CJ Date for example).
  
• Inside The Java Virtual Machine, by Bill Venners (McGraw-Hill): there are other books on the same subject. While this book has some bad reviews, I found it an easy read, and it explain well enough for me all the inner details of Java. I found "Programming for the Java Virtual Machine" not better, and with some bad example of a Prolog language for the JVM (1 full chapter for this to present a way too simple thing to be of any use).
• Programming Jabber, by O'Reilly: I have read it 2 years ago, I enjoyed how they made you go through building a Jabber server.
• Lucene In Action: the only book about Lucene, some of the info is useful to understand how it is designed.
• Hibernate In Action: if you have to use hibernate, this is the book to read. It presents different ways of using it.
• some Javascript+DHTML(+CSS) book: useful if you have none. They often have good tricks to solve the usual problems. In the AJAX days, it becomes useful again. I find O'Reilly's "Javascript - The Definitive Guide" good to have an API reference (as ebook), and "Javascript and DHTML Cookbook" has the most useful recipes.
• Lean Software Development by Poppendieck (Addison Wesley): easy to read, good presentation of software dev management problems and pragmatic solutions. My favorite on the subject. Another good one but very specific is "Requirements Management" (MS Press).
• UML Distilled by M Fowler: always useful to have if you need to draw UML diagrams.

Good Software Books - 2006 version

Here is an update of the most interesting software books I found interesting. I already made such a list in 2005:

• Object Oriented Software Construction, 2nd Ed, by Bertrand Meyer. This made me understand why OOP is important, what is important in OOP and why it is still relevant. It contains lots of important guidelines you can apply to better design programs. One famous quote is "Real systems have no top". Code Complete (Microsoft Press) covers some of the same ideas as Meyer's book, and some more pragmatic issues that arise in software projects ("measure twice, cut once"). I also liked the chapter on "table driven design".
• Concurrent Programming in Java, Second Edition, by Doug Lea: there is all you need to know about programming in a multithreaded environment in it. The chapter on synchronization should be a must read for every Java developer.
• Design Patterns by the GoF: simply the best presentation of most common design patterns. I have a glance on it once in a while.
  
• Artificial Intelligence through Prolog, by Neil C. Rowe (Prentice-Hall): if you don't remember much about Prolog, it's a good book. It details how Prolog interpreters work.
• File Systems Forensic Analysis, by Brian Carrier (Addison Wesley): everything you need to know about disks and file systems, every trick to recover lost data. To go more in depth into file systems theory, you can read the free Practical File System Design with the Be File System from D. Giampaolo, the creator of BeFS.
  
• Mind Hacks (O'Reilly): you probably already bought that one. Not about software, but excellent.
  
• Practical Issues in Database Management by Fabian Pascal (Addison Wesley): short but concise book on relational database theory. F Pascal is of CJ Date school of thoughts, "null are evil". You don't need to read it if you have read any other similar book (by CJ Date for example).
  
• Inside The Java Virtual Machine, by Bill Venners (McGraw-Hill): there are other books on the same subject. While this book has some bad reviews, I found it an easy read, and it explain well enough for me all the inner details of Java. I found "Programming for the Java Virtual Machine" not better, and with some bad example of a Prolog language for the JVM (1 full chapter for this to present a way too simple thing to be of any use).
• Programming Jabber, by O'Reilly: I have read it 2 years ago, I enjoyed how they made you go through building a Jabber server.
• Lucene In Action: the only book about Lucene, some of the info is useful to understand how it is designed.
• Hibernate In Action: if you have to use hibernate, this is the book to read. It presents different ways of using it.
• some Javascript+DHTML(+CSS) book: useful if you have none. They often have good tricks to solve the usual problems. In the AJAX days, it becomes useful again. I find O'Reilly's "Javascript - The Definitive Guide" good to have an API reference (as ebook), and "Javascript and DHTML Cookbook" has the most useful recipes.
• Lean Software Development by Poppendieck (Addison Wesley): easy to read, good presentation of software dev management problems and pragmatic solutions. My favorite on the subject. Another good one but very specific is "Requirements Management" (MS Press).
• UML Distilled by M Fowler: always useful to have if you need to draw UML diagrams.

I Get Spring

When you google up Java Spring, one of the best results is a post from crazybob called "I Don't Get Spring". For a long time, I shared a similar opinion. But now that I have used it, I get it. I only use it for defining replaceable services, so when I talk about Spring, I mean spring-core and spring-beans.

These two packages are not big, and have only very few dependencies. So it is quite easy to use Spring in any project, be it small or not. It is actually easier than using NanoContainer because Spring has less external dependencies.

I did not talk about Dependency Injection yet, because that was not my primary goal. Many times I had to write by hand configurable factories. By using Spring, I avoid writing all that boilerplate code. I was surprised that with 1 line of code I actually had my factory done. Granted, the config file is xml, an I am not necessarily an xml fan. But 1) it's very simple, and 2) if you don't want your custom factory to depend on all implementations, you will either use strings in your code or a config file, which in the end is no better than Spring config file.

Dependency Injection is the big plus that Springs gives on top of it. It's very useful to define your dependencies explicitly in the config file, since all beans instantiated from the config file are instantiated dynamically. And by defining the dependencies, you also get for free the injection.

Spring is not big and strange and unknown. It solves a fairly simple problem. But again I don't use it for everything, every class. I don't think it brings much versus straight Java code when you don't want replaceable services. And putting it in places where it is not needed would be dangerous, because of the unneeded xml configuration.

I Get Spring

When you google up Java Spring, one of the best results is a post from crazybob called "I Don't Get Spring". For a long time, I shared a similar opinion. But now that I have used it, I get it. I only use it for defining replaceable services, so when I talk about Spring, I mean spring-core and spring-beans.

These two packages are not big, and have only very few dependencies. So it is quite easy to use Spring in any project, be it small or not. It is actually easier than using NanoContainer because Spring has less external dependencies.

I did not talk about Dependency Injection yet, because that was not my primary goal. Many times I had to write by hand configurable factories. By using Spring, I avoid writing all that boilerplate code. I was surprised that with 1 line of code I actually had my factory done. Granted, the config file is xml, an I am not necessarily an xml fan. But 1) it's very simple, and 2) if you don't want your custom factory to depend on all implementations, you will either use strings in your code or a config file, which in the end is no better than Spring config file.

Dependency Injection is the big plus that Springs gives on top of it. It's very useful to define your dependencies explicitly in the config file, since all beans instantiated from the config file are instantiated dynamically. And by defining the dependencies, you also get for free the injection.

Spring is not big and strange and unknown. It solves a fairly simple problem. But again I don't use it for everything, every class. I don't think it brings much versus straight Java code when you don't want replaceable services. And putting it in places where it is not needed would be dangerous, because of the unneeded xml configuration.

Java Serialization vs .NET Serialization - Java Perverse?

Did you know what happens in Java when you serialize a subclass of a non serializable class? I was surprised by the answer: it works!

Unfortunately it is not a good thing, because it will serialize fields from your subclass and no fields from the parent class. So you'll end up with a half serialized instance.

In .NET, it breaks at runtime, throwing an exception, which is I think, much more logical, because then you don't end up with half data somewhere.

• Java Code:

import java.io.ByteArrayInputStream; import java.io.ByteArrayOutputStream; import java.io.ObjectInputStream; import java.io.ObjectOutputStream; import java.io.Serializable; public class Test {   public static class Toto    {     public String me;       }      public static class Toto2 extends Toto implements Serializable   {     public String you;     public String toString()     {       return me+" "+you;     }   }      public static void main(String[] args) throws Exception   {     Toto2 t = new Toto2();     t.me = "it's me";     t.you = "it's you";     System.out.println("t="+t);     ByteArrayOutputStream b = new ByteArrayOutputStream();     ObjectOutputStream oos = new ObjectOutputStream(b);     oos.writeObject(t);     ObjectInputStream ois = new ObjectInputStream(new ByteArrayInputStream(b.toByteArray()));     System.out.println("u="+ois.readObject());   } }

will output:
t=it's me it's you
u=null it's you

• .NET Code:

using System;
using System.Collections.Generic;
using System.Text;
using System.IO;
using System.Xml;
using System.Xml.Serialization;
using System.Runtime.Serialization.Formatters.Binary;

namespace ConsoleApplication
{
    public class Toto
    {
        public string me;
        public override string ToString()
       {
            return me;
       }
    }
  
    [Serializable]
    public class Toto2 : Toto
    {
        public string you;
        public override string ToString()
       {
            return you + " " + me;
        }
    } 

    class Program
    {
        static void Main(string[] args)
        {
            Toto2 t = new Toto2();
            t.me = "it's me";
            t.you = "it's you";
            using (FileStream fs = File.Create(@"c:\test.bin"))
           {
                BinaryFormatter bFormatter = new BinaryFormatter();
                bFormatter.Serialize(fs, t);
            }
            Console.WriteLine("t=" + t.ToString());
            Toto2u = null;
            using (FileStream fs = File.Open(@"c:\test.bin", FileMode.Open))
            {
                BinaryFormatter bFormatter = new BinaryFormatter();
                u = (Toto2)bFormatter.Deserialize(fs);
            }
            Console.WriteLine("u="+u.ToString());
            Console.ReadKey();
        }
    }
}

will throw an exception.

Java Serialization vs .NET Serialization - Java Perverse?

Did you know what happens in Java when you serialize a subclass of a non serializable class? I was surprised by the answer: it works!

Unfortunately it is not a good thing, because it will serialize fields from your subclass and no fields from the parent class. So you'll end up with a half serialized instance.

In .NET, it breaks at runtime, throwing an exception, which is I think, much more logical, because then you don't end up with half data somewhere.

• Java Code:

import java.io.ByteArrayInputStream; import java.io.ByteArrayOutputStream; import java.io.ObjectInputStream; import java.io.ObjectOutputStream; import java.io.Serializable; public class Test {   public static class Toto    {     public String me;       }      public static class Toto2 extends Toto implements Serializable   {     public String you;     public String toString()     {       return me+" "+you;     }   }      public static void main(String[] args) throws Exception   {     Toto2 t = new Toto2();     t.me = "it's me";     t.you = "it's you";     System.out.println("t="+t);     ByteArrayOutputStream b = new ByteArrayOutputStream();     ObjectOutputStream oos = new ObjectOutputStream(b);     oos.writeObject(t);     ObjectInputStream ois = new ObjectInputStream(new ByteArrayInputStream(b.toByteArray()));     System.out.println("u="+ois.readObject());   } }

will output:
t=it's me it's you
u=null it's you

• .NET Code:

using System;
using System.Collections.Generic;
using System.Text;
using System.IO;
using System.Xml;
using System.Xml.Serialization;
using System.Runtime.Serialization.Formatters.Binary;

namespace ConsoleApplication
{
    public class Toto
    {
        public string me;
        public override string ToString()
       {
            return me;
       }
    }
  
    [Serializable]
    public class Toto2 : Toto
    {
        public string you;
        public override string ToString()
       {
            return you + " " + me;
        }
    } 

    class Program
    {
        static void Main(string[] args)
        {
            Toto2 t = new Toto2();
            t.me = "it's me";
            t.you = "it's you";
            using (FileStream fs = File.Create(@"c:\test.bin"))
           {
                BinaryFormatter bFormatter = new BinaryFormatter();
                bFormatter.Serialize(fs, t);
            }
            Console.WriteLine("t=" + t.ToString());
            Toto2u = null;
            using (FileStream fs = File.Open(@"c:\test.bin", FileMode.Open))
            {
                BinaryFormatter bFormatter = new BinaryFormatter();
                u = (Toto2)bFormatter.Deserialize(fs);
            }
            Console.WriteLine("u="+u.ToString());
            Console.ReadKey();
        }
    }
}

will throw an exception.

5 Minutes of Google Spreadsheets

Today I noticed a Google Spreadsheets link in my gmail screen. I had read about it but never bothered to try before. In the finance industry, a lot of traders use excel, so I was wondering if Google spreadsheets could be another fit.

Unfortunately for Google, under Linux at least, I don't find Google Spreadsheets usable for anything else than storing and sharing some information, not often updated. Although I admire the engineers that managed to write the Javascript behind Google Spreasheet, it is way too slow for using it in interesting ways. Editing is slow, copy/paste is slow, sorting is slow.

I then wondered if it could read my contacts CSV from GMail (you can export contacts to a CSV file in Gmail). It could be a better interface to edit contacts. But strangely, importing Gmail CSV in Google Spreadsheets does not work.

I don't think I'll use it another 5 more minutes.

5 Minutes of Google Spreadsheets

Today I noticed a Google Spreadsheets link in my gmail screen. I had read about it but never bothered to try before. In the finance industry, a lot of traders use excel, so I was wondering if Google spreadsheets could be another fit.

Unfortunately for Google, under Linux at least, I don't find Google Spreadsheets usable for anything else than storing and sharing some information, not often updated. Although I admire the engineers that managed to write the Javascript behind Google Spreasheet, it is way too slow for using it in interesting ways. Editing is slow, copy/paste is slow, sorting is slow.

I then wondered if it could read my contacts CSV from GMail (you can export contacts to a CSV file in Gmail). It could be a better interface to edit contacts. But strangely, importing Gmail CSV in Google Spreadsheets does not work.

I don't think I'll use it another 5 more minutes.

Procedural Programming in an OO language

OO is an old buzzword, that is not required anymore to get an employment. Recruiter seems to prefer SOA, Web Services, and in France, "mutualisation" and "urbanisation". Sometimes I really wonder if OO made it.

I am sure many of you are confronted with programmers that love procedural programming in many of your projects. They might use an OO language but in the end will organize everything by "type", split invariably state and logic. Everything will be so much better stateless. And we will create lookup maps to glue everything back together. In a way I feel they remove the OO of the language.

It's not necessarily bad programming. Sometimes it is encouraged by standards, after all, that's the way most Javabeans are used. It can be preferable in some places, for example you don't want to mix your XML creating code in the object that has to be transformed to XML, this way of transforming objects to XML has been gone a long time ago in Java.

But the excess of it can be quite frustrating.

Procedural Programming in an OO language

OO is an old buzzword, that is not required anymore to get an employment. Recruiter seems to prefer SOA, Web Services, and in France, "mutualisation" and "urbanisation". Sometimes I really wonder if OO made it.

I am sure many of you are confronted with programmers that love procedural programming in many of your projects. They might use an OO language but in the end will organize everything by "type", split invariably state and logic. Everything will be so much better stateless. And we will create lookup maps to glue everything back together. In a way I feel they remove the OO of the language.

It's not necessarily bad programming. Sometimes it is encouraged by standards, after all, that's the way most Javabeans are used. It can be preferable in some places, for example you don't want to mix your XML creating code in the object that has to be transformed to XML, this way of transforming objects to XML has been gone a long time ago in Java.

But the excess of it can be quite frustrating.

Back To Real Java, Bye Bye J2EE

I changed job recently. In this new job, it is refreshing to see Java used like in the old days, without the J2EE layers, and without the extra IBM layers of my previous job. Granted, the fresh Java approach does not apply to many projects, because a lot of apps are just about interfacing a database with a web interface. But Spring success showed that even for many of those projects, fresh Java approach with a small framework is enough.

This makes me think about people (on the net) complaining that in some job interviews, candidates were not able to tell how to get a EJB instance, etc.. Those kind of question are really stupid, as what matters much much more are EJBs concepts and concerns, i.e. what it tries to solve and how it tried to solve it, and for example, what is good/bad about it.

Java is much nicer to use in the old way. Everything seems fast to do. I am surprised it is more pleasant to work with Java in this kind of environment than in a web/J2EE environment.

Back To Real Java, Bye Bye J2EE

I changed job recently. In this new job, it is refreshing to see Java used like in the old days, without the J2EE layers, and without the extra IBM layers of my previous job. Granted, the fresh Java approach does not apply to many projects, because a lot of apps are just about interfacing a database with a web interface. But Spring success showed that even for many of those projects, fresh Java approach with a small framework is enough.

This makes me think about people (on the net) complaining that in some job interviews, candidates were not able to tell how to get a EJB instance, etc.. Those kind of question are really stupid, as what matters much much more are EJBs concepts and concerns, i.e. what it tries to solve and how it tried to solve it, and for example, what is good/bad about it.

Java is much nicer to use in the old way. Everything seems fast to do. I am surprised it is more pleasant to work with Java in this kind of environment than in a web/J2EE environment.

Moving weekly Javablog stats to a new blog

Javablogs.com top 10 weekly/monthly/yearly entries were starting to pollute my blog too much for my taste. It is more appropriate to dedicate a blog to them. That is what I should have done in the first place as it is very easy to have many blogs with blogger.com.

So you'll find at javabuzz.blogspot.com the weekly top 10 most read entries on Javablogs, and sometimes more.

Moving weekly Javablog stats to a new blog

Javablogs.com top 10 weekly/monthly/yearly entries were starting to pollute my blog too much for my taste. It is more appropriate to dedicate a blog to them. That is what I should have done in the first place as it is very easy to have many blogs with blogger.com.

So you'll find at javabuzz.blogspot.com the weekly top 10 most read entries on Javablogs, and sometimes more.

JSF Was Too Hard for Experienced Developers

While starting to look into Seam, I noticed that all examples use JSF for the view, and there is no alternative to it. If someone like Gavin (from Hibernate fame) thinks JSF is usable, then I probably overlooked something when I looked into it a few years ago, when JSF was the craze of the moment.

At the beginning, JSF looks very similar to ASP.NET. But I have a small experience with ASP.NET, and ASP.NET is quite simple to understand and use. You can throw up inexperienced developers at it, they will manage to create something that works quite quickly. ASP.NET feels quite natural once you understand the postback thingy. JSF is another beast. Maybe part of it is due to the fact that the Java world has no excellent tools integration like Microsoft has (IBM RAD, one of the most advanced concerning integration, is quite far off). But there are also many technological reasons; when I read that article about JSF shortcomings with JSP, I was shocked that even to do very simple things, you would screw up, because simple things can be very complicated in JSF.

What seems to make JSF much nicer is Facelets, as it solves all problems related to JSP and JSF. This might make my JSF experience a good one, after all. I am curious to see if it makes JSF programming really nicer, and if Seam makes the overall very quick to build and understand.

JSF Was Too Hard for Experienced Developers

While starting to look into Seam, I noticed that all examples use JSF for the view, and there is no alternative to it. If someone like Gavin (from Hibernate fame) thinks JSF is usable, then I probably overlooked something when I looked into it a few years ago, when JSF was the craze of the moment.

At the beginning, JSF looks very similar to ASP.NET. But I have a small experience with ASP.NET, and ASP.NET is quite simple to understand and use. You can throw up inexperienced developers at it, they will manage to create something that works quite quickly. ASP.NET feels quite natural once you understand the postback thingy. JSF is another beast. Maybe part of it is due to the fact that the Java world has no excellent tools integration like Microsoft has (IBM RAD, one of the most advanced concerning integration, is quite far off). But there are also many technological reasons; when I read that article about JSF shortcomings with JSP, I was shocked that even to do very simple things, you would screw up, because simple things can be very complicated in JSF.

What seems to make JSF much nicer is Facelets, as it solves all problems related to JSP and JSF. This might make my JSF experience a good one, after all. I am curious to see if it makes JSF programming really nicer, and if Seam makes the overall very quick to build and understand.

Top 10 Most Read Last Week On Javablogs.com, Week 24

Most read last week

1. Sexiest photo ever (235): Heading off to Nerja (on the advice of Joe who will pay dearly if the ratio of fish 'n chip shops to tapas bars isn't on the right side of 95:05) for 2 weeks with 3 lovely girls and a... [read]


2. You are not a ‘real’ Java developer until… (217): You had to use JDK 1.3 on a real project. In 2006. You had to use JDK 1.3 on a real project because you had to use some ancient version of WebSphere. In 2006. [read]


3. Beautiful JavaScript Windows and Dialogs for your Application (200): French expert user-interface programmer Sebastien Gruhier releases latest version of his beautiful Prototype Windows code, based on Prototype and compatible with Scriptaculous effects. [read]


4. Spring 2.0 Docs Rocks! (185): Just perusing the Spring 2.0 docs after seeing some negative blog posts on it (Spring in general). Its been taking a beating on being too complex/heavy but hey it does the job. [read]


5. Software Team Turnover: Why Developers Leave (184): Found this very interesting article about ways on how to learn more about your software development team and thing a company should know on how to retain them. [read]


6. This is Just Depressing (175): This evening I was browsing some of the recent posts on the amsuing thedailywtf. [read]


7. Does Spring encourage bad coding? (161): Let's expand on Martin Fowler's naive example of the movie lister and movie finder. Without Spring this is how the code would look like // in MovieListerString genre = input.getGenre(); // action, [read]


8. Doing away with getters and setters (161): How many times have you written boiler plate get and set methods? Here is an interesting system that might do away with them altogether. [read]


9. How to be a Junior Developer Forever : part 1 (157): You know it's hard out here for a lead developer. It's about being half manager (babysitter) and half developer. It's not easy but it pays the bills. [read]

Most read last week-end

1. Does Spring encourage bad coding? (161): Let's expand on Martin Fowler's naive example of the movie lister and movie finder. Without Spring this is how the code would look like // in MovieListerString genre = input.getGenre(); // action, [read]


2. How to be a Junior Developer Forever : part 1 (157): You know it's hard out here for a lead developer. It's about being half manager (babysitter) and half developer. It's not easy but it pays the bills. [read]


3. Spring IoC: The Java Enterprise drug (153): By now I have used Spring in a significant number of projects, [read]


4. Our Grass is Greenest: OGNL and LINQ (138): Microsoft's New LINQ feature looks a lot like Java's OGNL. [read]


5. CSS Navigation showcase ... *Impressive* ! (122): You'll find it here That's pretty amazing ! [read]


6. Comparing Google's Picasa Web to Flickr (115): I find the Picasa photo organizer to be almost perfect, except for not having a Mac version. I set up a gallery of my travel pictures on Picasa Web a few days ago. [read]


7. Spring IoC: The Java Enterprise drug (111): Potential dangers of Spring IoC (Inversion of Control) [read]


8. 激情女球迷带起我要去看世界杯的欲望！ (107): 世界杯彩绘流行 哥斯达黎加美女分外妖娆 我爱世界杯！ [read]


9. Introduction to Neural Networks in Java (102): Ever want to write a program smarter than you are? Have a go at this book (yes book) on how to get started with neural networks and just where you might want to use them. [read]

Top 10 Most Read Last Week On Javablogs.com, Week 24

Most read last week

1. Sexiest photo ever (235): Heading off to Nerja (on the advice of Joe who will pay dearly if the ratio of fish 'n chip shops to tapas bars isn't on the right side of 95:05) for 2 weeks with 3 lovely girls and a... [read]


2. You are not a ‘real’ Java developer until… (217): You had to use JDK 1.3 on a real project. In 2006. You had to use JDK 1.3 on a real project because you had to use some ancient version of WebSphere. In 2006. [read]


3. Beautiful JavaScript Windows and Dialogs for your Application (200): French expert user-interface programmer Sebastien Gruhier releases latest version of his beautiful Prototype Windows code, based on Prototype and compatible with Scriptaculous effects. [read]


4. Spring 2.0 Docs Rocks! (185): Just perusing the Spring 2.0 docs after seeing some negative blog posts on it (Spring in general). Its been taking a beating on being too complex/heavy but hey it does the job. [read]


5. Software Team Turnover: Why Developers Leave (184): Found this very interesting article about ways on how to learn more about your software development team and thing a company should know on how to retain them. [read]


6. This is Just Depressing (175): This evening I was browsing some of the recent posts on the amsuing thedailywtf. [read]


7. Does Spring encourage bad coding? (161): Let's expand on Martin Fowler's naive example of the movie lister and movie finder. Without Spring this is how the code would look like // in MovieListerString genre = input.getGenre(); // action, [read]


8. Doing away with getters and setters (161): How many times have you written boiler plate get and set methods? Here is an interesting system that might do away with them altogether. [read]


9. How to be a Junior Developer Forever : part 1 (157): You know it's hard out here for a lead developer. It's about being half manager (babysitter) and half developer. It's not easy but it pays the bills. [read]

Most read last week-end

1. Does Spring encourage bad coding? (161): Let's expand on Martin Fowler's naive example of the movie lister and movie finder. Without Spring this is how the code would look like // in MovieListerString genre = input.getGenre(); // action, [read]


2. How to be a Junior Developer Forever : part 1 (157): You know it's hard out here for a lead developer. It's about being half manager (babysitter) and half developer. It's not easy but it pays the bills. [read]


3. Spring IoC: The Java Enterprise drug (153): By now I have used Spring in a significant number of projects, [read]


4. Our Grass is Greenest: OGNL and LINQ (138): Microsoft's New LINQ feature looks a lot like Java's OGNL. [read]


5. CSS Navigation showcase ... *Impressive* ! (122): You'll find it here That's pretty amazing ! [read]


6. Comparing Google's Picasa Web to Flickr (115): I find the Picasa photo organizer to be almost perfect, except for not having a Mac version. I set up a gallery of my travel pictures on Picasa Web a few days ago. [read]


7. Spring IoC: The Java Enterprise drug (111): Potential dangers of Spring IoC (Inversion of Control) [read]


8. 激情女球迷带起我要去看世界杯的欲望！ (107): 世界杯彩绘流行 哥斯达黎加美女分外妖娆 我爱世界杯！ [read]


9. Introduction to Neural Networks in Java (102): Ever want to write a program smarter than you are? Have a go at this book (yes book) on how to get started with neural networks and just where you might want to use them. [read]

On EJB Restrictions - Can You Open a Socket?

During job interviews, one of the frequent questions is "What restrictions are imposed on EJBs?". I had a chat recently with someone about it, and we still don't agree on the answer.

He believes we can't open sockets, while I believe it is perfectly allowed, if you don't retain the socket connection between method calls.

His arguments are based on an analogy with files. After all in Linux, files are sockets. Here are his interpretations on a document about EJB restrictions on java.sun.com:

1. Passivation affects server sockets. Why client sockets are not affected by passivation is not mentioned. I suspect that given that the socket mechanism is the same in both cases (IP packets), there should be no difference.
2. EJBs are not allowed to access files because files are not transactional. Well, it is my understanding that sockets are neither.
3. Deployability. The file open in one JVM will not necessarily be open in another JVM. It is my understanding that the same will happen on sockets.

Now here is my reply:

The reference I mentioned says you can not open server sockets, because to use them, you would have to let them open between methods calls, otherwise you can't do anything with your server socket.

1. Passivation will only happen after or before a method call, not in the middle.
2. Good point, rollback seems hard with sockets.
3. The real problem with files and deployability is about clustering. I quote the same source: "if an enterprise bean running in a JVM on a particular machine is using or holding an open file descriptor to a file in the filesystem, that enterprise bean cannot easily be moved from one JVM or machine to another, without losing its reference to the file." Basically it says what's bad with files is if you use them to store some kind of state, because then this state will be different on different servers. This issue does not exist with sockets. What you mention is simply a configuration issue. Your datasources will vary as well from one JVM to another (on different servers).
   

I have the advantage that my interpretation is more common. But his arguments are still clever and EJBs specs could have been a bit more explicit about the use of java.io.Socket. Here is the line about it in the specs:

"The EJB architecture allows an enterprise bean instance to be a network socket client, but it does not allow it to be a network server. Allowing the instance to become a network server would conflict with the basic function of the enterprise bean-- to serve the EJB clients"

Our disagreement shows how such a simple subject, what you can and can't do in EJBs, is most of the time badly understood.

On EJB Restrictions - Can You Open a Socket?

During job interviews, one of the frequent questions is "What restrictions are imposed on EJBs?". I had a chat recently with someone about it, and we still don't agree on the answer.

He believes we can't open sockets, while I believe it is perfectly allowed, if you don't retain the socket connection between method calls.

His arguments are based on an analogy with files. After all in Linux, files are sockets. Here are his interpretations on a document about EJB restrictions on java.sun.com:

1. Passivation affects server sockets. Why client sockets are not affected by passivation is not mentioned. I suspect that given that the socket mechanism is the same in both cases (IP packets), there should be no difference.
2. EJBs are not allowed to access files because files are not transactional. Well, it is my understanding that sockets are neither.
3. Deployability. The file open in one JVM will not necessarily be open in another JVM. It is my understanding that the same will happen on sockets.

Now here is my reply:

The reference I mentioned says you can not open server sockets, because to use them, you would have to let them open between methods calls, otherwise you can't do anything with your server socket.

1. Passivation will only happen after or before a method call, not in the middle.
2. Good point, rollback seems hard with sockets.
3. The real problem with files and deployability is about clustering. I quote the same source: "if an enterprise bean running in a JVM on a particular machine is using or holding an open file descriptor to a file in the filesystem, that enterprise bean cannot easily be moved from one JVM or machine to another, without losing its reference to the file." Basically it says what's bad with files is if you use them to store some kind of state, because then this state will be different on different servers. This issue does not exist with sockets. What you mention is simply a configuration issue. Your datasources will vary as well from one JVM to another (on different servers).
   

I have the advantage that my interpretation is more common. But his arguments are still clever and EJBs specs could have been a bit more explicit about the use of java.io.Socket. Here is the line about it in the specs:

"The EJB architecture allows an enterprise bean instance to be a network socket client, but it does not allow it to be a network server. Allowing the instance to become a network server would conflict with the basic function of the enterprise bean-- to serve the EJB clients"

Our disagreement shows how such a simple subject, what you can and can't do in EJBs, is most of the time badly understood.

Top 10 Most Read Last Week On Javablogs.com, Week 23

Most read last week

1. The Top 10 Java Killer Apps (357): Some VERY cool apps that have created, or are creating, quite a buzz not only in the Java world but in the larger populace. I’ve used most of the apps below, although I have yet to try a few. [read]


2. Google hits a home run with Google Spreadsheet (290): I just got my invite to play with the latest offering from Google, the Google Spreadsheets and my initial reaction after playing with it for the past hour is incredibly positive. [read]


3. Agile people still don't get it (279): I just attended a presentation by Jeff Langr about Test-Driven Development which represents everything that is wrong about the way Agile advocates are trying to evangelize their practices. [read]


4. Whoa ... Spring doesn't lazily instantiate beans? (207): Just stumbled across a blog about Lazy Bean instantiation in Spring 2.0. This is kind of funny to me ... lazy instantiation is so important, so part of the base line of IoC container functionality, [read]


5. 6 Common Errors in Setting Java Heap Size (198): Two JVM options are often used to tune JVM heap size: -Xmx for maximum heap size, and -Xms for initial heap size. Here are some common mistakes I have seen when using them: Missing m, M, [read]


6. Google it? Not anymore... (198): I‘m disappointed in Google, to be honest. While I‘m not one of those Google-loving fly boys out there who think they can do no wrong, [read]


7. Would someone please explain Spring to me? (195): I'm dense. It's true. I'm not particularly quick to pick up on new concepts. I suppose if I encountered new concepts more often, I'd get better at assimilating. Instead, [read]


8. Take that .NET! (191): As an outspoken advocate of Java distributed computing, I was recently confronted by a group of .NET enthusiasts. They felt compelled go on about how much more "advanced" . [read]


9. Spring, what a crappy framework (184): I have this crappy theme going. In all seriousness, the Spring framework isn't crappy. As I've mentioned before, I like its promotion of interfaces - code to interfaces, not implementation, [read]

Most read last week-end

1. Spring, what a crappy framework (184): I have this crappy theme going. In all seriousness, the Spring framework isn't crappy. As I've mentioned before, I like its promotion of interfaces - code to interfaces, not implementation, [read]


2. Eclipse3.2 Splash Screen Final Release (157): As you know I have been creating splash screens for Eclipse Releases. This the final splash screen for the Eclipse Callisto 3. [read]


3. Spring MVC or Webwork ? (124): Disclaimer::To start with, I'm new to both of these frameworks and am looking at both of them with a fresh pair of eyes. [read]


4. World's funniest joke (116): A couple of New Jersey hunters are out in the woods when one of them falls to the ground. He doesn't seem to be breathing, his eyes are rolled back in his head. [read]


5. Agile Developers don't do Design (93): James Carr is back blogging after a year's absence and writes that we don't use UML in XP. [read]


6. Google And The Puzzle of Dropping Eggs (87): Google is also known for its interesting interview questions. Enjoy this one and my solution. Suppose you have two eggs. [read]


7. FireFox, the Next another Platform (86): We see the Web 2.0 is come to reality, and the apps move to web, google as the platform for provider, and firefox as the apps to access the platform, [read]


8. Why Java code is bad for rules and a declarative alternative (78): One of the selling features of Drools, and one of the reasons we are often chosen over competitors, [read]


9. 86 rules while you are at a bar (78): It happens that I live just across a dive bar... Also, I have really started appreciating Scotch recently Anyway, [read]