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]

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]

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

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?

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

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?

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

Most read last week

1. Why I'm leaving Sun and... what next? (304): Leaving Sun is possibly one of the most difficult decisions I've ever made. But I think it's time for me to start new things and, well, it's also time for Sun to start new things. [read]


2. 9 new and *noteworthy* features in Eclipse 3.2 (280): Chris Laffra has put a big presentation of all the new and noteworthy features that are coming in the Eclipse 3.2 platform.There is lots of screenshots, [read]


3. Don’t you just love it when Microsoft is forced to use Java? (253): Don’t you just love it when Microsoft is forced to use Java? [read]


4. Joshua Bloch Shocking Confession: java.util.Arrays Is Broken (218): (This should be all over the net by now. I first saw it here. [read]


5. Signs You're a Crappy Programmer (and don't know it) (212): This ought to put a smile on your face unless it hits too close to home! [read]


6. Spring starts you programming in pure XML! (211): I'm now very enthusiastic, some may say obsessed, about using the Spring Framework. Spring is certainly making me more productive. [read]


7. Google's GWT Example: Interactive FIFA 2006 World Cup Application (203): Goto the application without reading the entry.A couple of weeks ago google released the Google Web Toolkit. The toolkit lets Java developers create AJAX application, [read]


8. Testicular Cancer (198): I've just been diagnosed with testicular cancer. It's probably seminoma (which is relatively good). However, other things are now on my mind and so this blog will not be updated for a while. [read]


9. Intel iMac - the best Java development box in the world (182): Cancelling my MacBook Pro order worked out really well for me. Firstly, I'm getting a new company laptop (a big grey Dull), and the prospect of carrying two laptops around just scares me. Second, [read]

Most read last week-end

1. Joshua Bloch Shocking Confession: java.util.Arrays Is Broken (218): (This should be all over the net by now. I first saw it here. [read]


2. Hibernate3, Annotations & Spring: the morning after (116): Ok, after fiddling with a few more jars, I seem to have gotten past my main obsticle. Now I'm back to the "common problems" phase of working with Hibernate. Still evaluating, [read]


3. JBoss Seam: Make Spring inside (111): We here try out JBoss Seam, and find JBoss Microkernel, is this a IOC from JBoss? Why dont we use Spring instead? [read]


4. Why are we still dealing with C++ vs Java (97): I had an interesting conversation this week with someone that believed that the Java world was filled with people who couldn’t code. In his opinion, [read]


5. "Look Ma, no locks!" (97): Brian Goetz has written an excellent introductory article on nonblocking algorithms and showcases some simple nonblocking data structures with code examples and pictures. [read]


6. 6 Ways of Setting Java Classpath (96): How to set Java classpath? List as many ways as you can. This can be an interesting Java job interview question. [read]


7. Spring, JBoss and The Elephant (96): Interface 21 and BEA recently announced the release of Pitchfork, the EJB3 implementation within the Weblogic container, built using Spring. [read]


8. Ubuntu 6.06 (94): I upgraded my Ubuntu box the other night. The process was pretty impressive. For one thing, it was significantly faster than an MSWindows or MacOS upgrade. [read]


9. Integrating spring and GWT (84): I just completed my first shot at integrating Spring with GWT. You can check it out here Here’s what you do to expose a simple service. 1) Write the remote service, [read]

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

Most read last week

1. Why I'm leaving Sun and... what next? (304): Leaving Sun is possibly one of the most difficult decisions I've ever made. But I think it's time for me to start new things and, well, it's also time for Sun to start new things. [read]


2. 9 new and *noteworthy* features in Eclipse 3.2 (280): Chris Laffra has put a big presentation of all the new and noteworthy features that are coming in the Eclipse 3.2 platform.There is lots of screenshots, [read]


3. Don’t you just love it when Microsoft is forced to use Java? (253): Don’t you just love it when Microsoft is forced to use Java? [read]


4. Joshua Bloch Shocking Confession: java.util.Arrays Is Broken (218): (This should be all over the net by now. I first saw it here. [read]


5. Signs You're a Crappy Programmer (and don't know it) (212): This ought to put a smile on your face unless it hits too close to home! [read]


6. Spring starts you programming in pure XML! (211): I'm now very enthusiastic, some may say obsessed, about using the Spring Framework. Spring is certainly making me more productive. [read]


7. Google's GWT Example: Interactive FIFA 2006 World Cup Application (203): Goto the application without reading the entry.A couple of weeks ago google released the Google Web Toolkit. The toolkit lets Java developers create AJAX application, [read]


8. Testicular Cancer (198): I've just been diagnosed with testicular cancer. It's probably seminoma (which is relatively good). However, other things are now on my mind and so this blog will not be updated for a while. [read]


9. Intel iMac - the best Java development box in the world (182): Cancelling my MacBook Pro order worked out really well for me. Firstly, I'm getting a new company laptop (a big grey Dull), and the prospect of carrying two laptops around just scares me. Second, [read]

Most read last week-end

1. Joshua Bloch Shocking Confession: java.util.Arrays Is Broken (218): (This should be all over the net by now. I first saw it here. [read]


2. Hibernate3, Annotations & Spring: the morning after (116): Ok, after fiddling with a few more jars, I seem to have gotten past my main obsticle. Now I'm back to the "common problems" phase of working with Hibernate. Still evaluating, [read]


3. JBoss Seam: Make Spring inside (111): We here try out JBoss Seam, and find JBoss Microkernel, is this a IOC from JBoss? Why dont we use Spring instead? [read]


4. Why are we still dealing with C++ vs Java (97): I had an interesting conversation this week with someone that believed that the Java world was filled with people who couldn’t code. In his opinion, [read]


5. "Look Ma, no locks!" (97): Brian Goetz has written an excellent introductory article on nonblocking algorithms and showcases some simple nonblocking data structures with code examples and pictures. [read]


6. 6 Ways of Setting Java Classpath (96): How to set Java classpath? List as many ways as you can. This can be an interesting Java job interview question. [read]


7. Spring, JBoss and The Elephant (96): Interface 21 and BEA recently announced the release of Pitchfork, the EJB3 implementation within the Weblogic container, built using Spring. [read]


8. Ubuntu 6.06 (94): I upgraded my Ubuntu box the other night. The process was pretty impressive. For one thing, it was significantly faster than an MSWindows or MacOS upgrade. [read]


9. Integrating spring and GWT (84): I just completed my first shot at integrating Spring with GWT. You can check it out here Here’s what you do to expose a simple service. 1) Write the remote service, [read]

Is Java Flawed - a big advantage of Python/Ruby/(your favorite interpreted language)

Java is supposed to be much better to build big projects, because of static type checking, and all the rigour around the language. But how many of you have seen medium sized projects taking more than 30 minutes to build.

At work, they have a standard J2EE project, with only about 50 EJBs, hundreds of JDO classes, and standard classes. Between the JDO generation, EJB generation, EJB dependencies calculations, and packaging, it takes 20 minutes. And the project is not doing that much. One can optimize to avoid dependencies calculations and it would then take about 12 minutes. But still.

With Python, Ruby or your favorite interpreted language, this would be at most a few seconds to test a new version. Now I am a fan of Java and don't enjoy that much programming in interpreted languages, especially since modern IDE like Eclipse do so much for you.

To sum up, Java is supposed to be the right language for large scale projects, and yet it is on large scale projects that compilation is an issue. Ok, this will enforces a better separation of concerns, and will probably be beneficial in the end. But I am not sure that most people do a good separation of concerns in projects they manage.

I think it is no accident if the next step in Java development involves much more runtime compilation. It somehow started with JSPs, and then with the various XML config files combined to java reflection. It is now made even more popular with annotations, see EJB 3.0.

I am wondering a bit if one day compiled languages will be only a curiosity for most enterprise projects.

Is Java Flawed - a big advantage of Python/Ruby/(your favorite interpreted language)

Java is supposed to be much better to build big projects, because of static type checking, and all the rigour around the language. But how many of you have seen medium sized projects taking more than 30 minutes to build.

At work, they have a standard J2EE project, with only about 50 EJBs, hundreds of JDO classes, and standard classes. Between the JDO generation, EJB generation, EJB dependencies calculations, and packaging, it takes 20 minutes. And the project is not doing that much. One can optimize to avoid dependencies calculations and it would then take about 12 minutes. But still.

With Python, Ruby or your favorite interpreted language, this would be at most a few seconds to test a new version. Now I am a fan of Java and don't enjoy that much programming in interpreted languages, especially since modern IDE like Eclipse do so much for you.

To sum up, Java is supposed to be the right language for large scale projects, and yet it is on large scale projects that compilation is an issue. Ok, this will enforces a better separation of concerns, and will probably be beneficial in the end. But I am not sure that most people do a good separation of concerns in projects they manage.

I think it is no accident if the next step in Java development involves much more runtime compilation. It somehow started with JSPs, and then with the various XML config files combined to java reflection. It is now made even more popular with annotations, see EJB 3.0.

I am wondering a bit if one day compiled languages will be only a curiosity for most enterprise projects.

Using Linux to Recover Fucked Up Windows Data

Recently, one of my relatives computer under Windows XP, refused to boot. There was no way of fixing it with Windows Install CD as partition table seemed corrupt to Windows. I tried everything in an 2003 Ultimate Boot CD, but nothing worked out.

Someone gave me an install cd of Ubuntu Linux, and it managed to read the data. Well sometimes only. The erratic behaviour was due to a bad ATA cable. This probably was the cause of the corruption in the first place. Anyway with a new cable, Windows was still not able to read its data. But Ubuntu Linux, now working well, was able to, without having anything to configure (except mounting the drive).

So I copied the data, and reformated the NTFS partition, reinstalled Windows, recopied the data.

After this experience, I'd recommend to any Windows user to have a spare Ubuntu Linux Live CD, just in case your Windows corrupts itself.

Using Linux to Recover Fucked Up Windows Data

Recently, one of my relatives computer under Windows XP, refused to boot. There was no way of fixing it with Windows Install CD as partition table seemed corrupt to Windows. I tried everything in an 2003 Ultimate Boot CD, but nothing worked out.

Someone gave me an install cd of Ubuntu Linux, and it managed to read the data. Well sometimes only. The erratic behaviour was due to a bad ATA cable. This probably was the cause of the corruption in the first place. Anyway with a new cable, Windows was still not able to read its data. But Ubuntu Linux, now working well, was able to, without having anything to configure (except mounting the drive).

So I copied the data, and reformated the NTFS partition, reinstalled Windows, recopied the data.

After this experience, I'd recommend to any Windows user to have a spare Ubuntu Linux Live CD, just in case your Windows corrupts itself.