I Get Spring

Wed, Aug 23, 2006

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?

Tue, Aug 22, 2006 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

Thu, Aug 17, 2006

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

Tue, Aug 8, 2006

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

Wed, Jul 26, 2006

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

Mon, Jun 26, 2006

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

Fri, Jun 23, 2006

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.

On EJB Restrictions - Can You Open a Socket?

Mon, Jun 19, 2006

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:

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.
EJBs are not allowed to access files because files are not transactional. Well, it is my understanding that sockets are neither.
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. Passivation will only happen after or before a method call, not in the middle. Good point, rollback seems hard with sockets. 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.