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.

Non Blocking with Traditional Java IO - On the Use of InputStream.available() and Thread.sleep()

Thu, Jun 8, 2006 Some time ago I did quite a lot of IO in Java and I yet did not see this way of reading a InputStream from a Socket:

    InputStream in=channel.getInputStream();

    channel.connect();

    byte[] tmp=new byte[1024];
    while(true){
      while(in.available()>0){
        int i=in.read(tmp, 0, 1024);
        if(i<0)break;
        System.out.print(new String(tmp, 0, i));
      }
      if(channel.isClosed()){
        System.out.println("exit-status: "+channel.getExitStatus());
        break;
      }
      try{Thread.sleep(1000);}catch(Exception ee){}
    }
    channel.disconnect();

This comes from a piece of code from an example of JSch , a good ssh client in java. A work collegue had the bad idea to remove the Thread.sleep call and was struggling with why it would randomly work.The way I would have done it is the following:

    InputStream in=channel.getInputStream();

    channel.connect();

    byte[] tmp=new byte[1024];
    int bytesRead = 0;
    while((bytesRead = in.read(tmp,0,1024) >= 0){
      System.out.print(new String(tmp, 0, bytesRead));
    }

    if(channel.isClosed()){
      System.out.println("exit-status: "+channel.getExitStatus());
      break;
    }
    channel.disconnect();

This has the advantage of being more readable and having less secret spices in it. In the first code, the call to available() is non blocking, meaning that without the Thread.sleep(), there will never be the time for the socket buffer to fill up. But is the first code more efficient or the second code?

I did a search on google to understand the interest of the first code. The only advantages I found in the first code are the possibility to interrupt the thread running the code and a finer grained control on timeouts.

There is a lengthy explanation by Doug Lea in his book "Concurrent Programming in Java". This book usually provides excellent explanations, and is a must read for anybody doing concurrent programming. But this time, about this subject, I did not find him that clear.

There is a more simple explanation in a course from San Diego State University (see last example)

A read() on an inputstream or reader blocks. Once a thread calls read() it will not respond to interrupt() (or much else) until the read is completed. This is a problem when a read could take a long time: reading from a socket or the keyboard. If the input is not forth coming, the read() could block forever.

As usual, you should not rely on all what you read on the web, as this page (SCJP Questions & Answers) testifies:

Q. When will a Thread I/O blocked?

A:

When a thread executes a read() call on an InputStream, if no byte is available. The calling Thread blocks, in other words, stops executing until a byte is available or the Thread is interrupted.

Still I am wondering if the second code would not just go into IOException (socket timeout), on timeout (adjustable with Socket.setTimeout ) and release the Thread then. Do you have an idea when the first code could be better?